ANEXOS

Introdução ao Processo Unificado

O Processo Unificado (PU) surgiu como um processo popular para o
desenvolvimento de software visando à construção de sistemas orientados
a objetos.

Introdução

O Processo Unificado (PU) surgiu como um processo popular para o desenvolvimento de software visando à

construção de sistemas orientados a objetos (o RUP – Rational Unified Process é um refinamento do PU). É

um processo iterativo e adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos devido a

maneira organizada e consistente que permite conduzir um projeto. Este artigo apresenta uma breve

introdução das práticas e abordagens adotadas pelo PU (Basicamente um resumo do capitulo referente ao

PU do livro Utilizando UML e Padrões de Craig Larman).

Principal Idéia: Desenvolvimento Iterativo e Incremental

O PU utiliza um paradigma evolucionário paro o desenvolvimento de softwares. O ciclo de vida iterativo é

baseado em refinamentos e incrementos sucessivos a fim de convergir para um sistema adequado. Em cada

iteração incrementa-se um pouco mais o produto, baseando-se na experiência obtida nas iterações anteriores

e no feedback do usuário. Cada iteração pode ser considerada um miniprojeto de duração fixa, sendo que

cada um destes inclui suas próprias atividades de análise de requisitos, projeto, implementação e testes.
Figura 1 – Desenvolvimento iterativo e incremental.

O resultado de cada iteração é um sistema executável, porém incompleto. Ele não está pronto para ser

colocado em produção e pode continuar nesta situação ainda por muitas iterações. Vale ressaltar também

que cada iteração produz um sistema com qualidade de produto final, e não um protótipo.

Realimentação e Adaptação: A chave para o sucesso!

Ao invés de combater a inevitável mudança que ocorre no desenvolvimento de software (principalmente nas

fases iniciais), o PU prega uma atitude de aceitar a mudança e a adaptação como fatores inevitáveis e,

de fato, essenciais. Não se deve tentar especificar completa e corretamente o sistema em uma tacada só, com

a idéia de criar um conjunto congelado de requisitos.

Em cada iteração é escolhido um pequeno subconjunto de requisitos, os quais são rapidamente projetados,

implementados e testados pelos usuários. Isso leva a uma realimentação rápida - baseada em dados

concretos de usuários, desenvolvedores e testes – que possibilita modificar ou adaptar a compreensão dos
requisitos do projeto. Os usuários finais podem ver um sistema parcial, utilizá-lo e assim terão mais

subsídios para criticar ou aprovar. Esse ciclo de avaliações e detecção de falhas não traduz um erro, mas

sim, representam um modo hábil de progredir e descobrir o que é de real valor para os interessados

no projeto. Além de melhorar a compreensão dos requisitos, a implementação precoce possibilita detectar

se o projeto está no caminho certo ou, por exemplo, se alguma mudança na arquitetura central deve ser feita.

Consequentemente o trabalho progride por meio de uma série de ciclos estruturados em construção-

realimentação- adaptação. É melhor resolver e por à prova as decisões arriscadas e fundamentais de projeto

logo no início e o desenvolvimento iterativo fornece o mecanismo para isso.

Resumindo, os principais benefícios do PU são:

? mitigação precoce, ao invés de tardia, de altos riscos;

? progresso visível desde o início;

? realimentação, envolvimento do usuário e adaptação imediatos, levando a um sistema refinado que

atenda, de forma mais adequada, às reais necessidades dos interessados;

? a complexidade é administrada; a equipe não é sobrecarregada pela “paralisia da análise” ou por

passos muito longos e complexos;

? o aprendizado obtido em uma iteração pode ser usado para melhorar o próprio processo de

desenvolvimento.

Fases do PU
É altamente recomendado pelo PU que as iterações tenham tempo fixo pré-determinado e que se cumpra o

prazo de cada iteração. Iterações pequenas, entre duas a seis semanas, é o ideal pois são mais gerenciáveis e

permitem rápida realimentação e adaptações. Iterações longas subvertem a motivação central para o

desenvolvimento iterativo e aumentam o risco do projeto.

O Processo Unificado organiza suas iterações em quatro fases principais:

1. Concepção: o objetivo desta fase é levantar, de forma genérica e pouco precisa,

o escopo do projeto. Não deve existir aqui a pretensão de especificar de forma
detalhada requisitos, a idéia é ter uma visão inicial do problema, estimar de
forma vaga esforço e prazos e determinar se o projeto é viável e merece uma
análise mais profunda.
2. Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos)
são levantados em detalhes. Numa primeira iteração um ou dois requisitos, os
de maior risco e valor arquitetural, são especificados em detalhes. Estes são
implementados e servem como base de avaliação junto ao usuário e
desenvolvedores para o planejamento da próxima iteração. Em cada nova
iteração na fase de elaboração pode haver um seminário de requisitos, onde
requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da
fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi
implementado com alta qualidade, os principais riscos foram tratados e pode-se
então fazer estimativas mais realistas.
3. Construção: implementação iterativa dos elementos restantes de menor risco e
mais fáceis e preparação para a implantação.
4. Transição: testes finais e implantação.
Figura 2 – Esboço do cronograma de um PU.

Conclusão

O Processo Unificado foi criado para ser um processo ágil de desenvolvimento e prega uma abordagem

realística para a condução de um projeto. Ao contrário do modelo em cascata, onde cada etapa do ciclo de

vida é realizada integralmente e de uma só vez (e que é mais apropriado para a construção de prédios do que

para softwares), no PU as atividades são repetidas quantas vezes forem preciso, em ciclos organizados. Não

há um plano detalhado para todo um projeto. Há um plano de alto nível (chamado Plano de Fases) que

estima a data de término do projeto e outros marcos de referência principais, mas ele não detalha os passos

de granularidade fina para se atingir tais marcos. Um plano detalhado (chamado Plano de Iterações) somente

planeja a iteração a ser feita em seguida. O planejamento detalhado é feito de forma adaptativa, de iteração

para iteração.

UML
Por Marina Martinez

A UML (Unified Modeling Language), que significa Linguagem Unificada de

Modelagem é uma linguagem padrão para modelagem orientada a objetos. Ela surgiu
da fusão de três grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE (Jacobson).
Esta linguagem de modelagem não proprietária de terceira geração, não é um
método de desenvolvimento. Têm como papel auxiliar a visualizar o desenho e a
comunicação entre objetos. Ela permite que desenvolvedores visualizem os produtos
de seu trabalho em diagramas padronizados, e é muito usada para criar modelos de
sistemas de software.
Além de fornecer a tecnologia necessária para apoiar a prática de engenharia de
softwareorientada a objetos, a UML poderá ser a linguagem de modelagem padrão
para modelar sistemas concorrentes e distribuídos. Utiliza-se de um conjunto de
técnicas de notação gráfica para criar modelos visuais de software de sistemas
intensivos, combinando as melhores técnicas de modelagem de dados, negócios,
objetos e componentes. É uma linguagem de modelagem única, comum e
amplamente utilizável.

Embora com a UML seja possível representar o software através de modelos

orientados a objetos, ela não demonstra que tipo de trabalho deve ser feito, ou seja,
não possui um processo que define como o trabalho tem que ser desenvolvido. O
objetivo então é descrever "o que fazer", "como fazer", "quando fazer" e "porque
deve ser feito". É necessária a elaboração completa de um dicionário de dados, para
descrever todas as entidades envolvidas, refinando, com isso, os requisitos funcionais
do software.

A Linguagem Unificada de Modelagem possui diagramas (representações gráficas do

modelo parcial de um sistema) que são usados em combinação, com a finalidade de
obter todas as visões e aspectos do sistema.

Os Diagramas da UML estão divididos em Estruturais e Comportamentais.

Diagramas Estruturais
De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de
apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de
classes com seus atributos e métodos e os relacionamentos entre classes.
De Objeto: O diagrama de objeto esta relacionado com o diagrama de classes
e, é praticamente um complemento dele. Fornece uma visão dos valores
armazenados pelos objetos de um Diagrama de Classe em um determinado
momento da execução do processo do software.
De Componentes: Está associado à linguagem de programação e tem por
finalidade indicar os componentes do software e seus relacionamentos.
De implantação: Determina as necessidades de hardware e características
físicas do Sistema.
De Pacotes: Representa os subsistemas englobados de forma a determinar
partes que o compõem.
De Estrutura: Descreve a estrutura interna de um classificador.

Diagramas Comportamentais
 De Caso de Uso (Use Case): Geral e informal para fases de levantamento
e análise de Requisitos do Sistema.
De Máquina de Estados: Procura acompanhar as mudanças sofridas por um
objeto dentro de um processo.
De Atividades: Descreve os passos a serem percorridos para a conclusão de
uma atividade.
De Interação: Dividem-se em:
1. De Sequência: Descreve a ordem temporal em que as mensagens são
trocadas entre os objetos.
2. Geral interação: Variação dos diagramas de atividades que fornece visão
geral dentro do sistema ou processo do negócio.
3. De comunicação: Associado ao diagrama de Seqüência, complementando-
o e concentrando-se em como os objetos estão vinculados.
4. De tempo: Descreve a mudança de estado ou condição de uma instância
de uma classe ou seu papel durante o tempo.

Diagramas da UML

O que significa Orientação a objetos ?

Orientação a objeto é um conceito que esta relacionado com a ideia de classificar ,

organizar e abstrair coisas. Veja a definição formal:
"O termo orientação a objetos significa organizar o mundo real como uma
coleção de objetos que incorporam estrutura de dadose um conjunto de
operações que manipulam estes dados. "

Vamos falar uma linguagem mas simples para isto vamos para um ambiente que você
conhece bem: A sua casa !

Agora vamos olhar a sua estante , o seu guarda-roupa , o seu armário , a sua cozinha.
Em todos estes lugares você classificou coisas no seu domínio e , somente de olhar
para eles você já sabe relacionar a classificação que utilizou em cada um deles e
como classificou as coisas que estão neste lugares.

Na estante você agrupou e organizou os livros , no guarda roupa suas camisas, calças
, meias , ternos , etc. Todos os objetos que você classificou nestes lugares foram
organizados baseado em alguma concepção que você possuía sobre eles.

No contexto orientado a objeto a estante , o armário , a cozinha são chamados de

classes.

No contexto de software podemos dizer que :

Uma classe é um gabarito para a definição de objetos. Através da definição de

uma classe, descreve-se que propriedades -- ou atributos -- o objeto terá.

Uma classe mantém dois elementos importantes : estrutura e comportamento.

Uma estrutura representa os atributos que descrevem a classe.
Um comportamento representa os serviços que a classe suporta.
Na 'classe' do seu guarda-roupa , uma camisa amarela pode ser colocada em uma
outra classe. A 'classe' camisa.
Cada camisa tem uma estrutura que é : a textura , a cor , o tamanho e o
modelo.
Cada camisa tem um comportamento que é : ordenar , rasgar , desbotar .
Se você concordar que existe uma classe camisa. Vai concordar que existem diversos
tipos de camisas com suas características, ou seja , existem diversos objetos camisas
que podem ser criados a partir da classe camisa. Daí temos o conceito de objetos:

O conceito de orientação a objetos é abordado desta mesma maneira sempre. No

contexto do software podemos então dizer que :

É através de objetos que (praticamente) todo o processamento ocorre em

aplicações desenvolvidas com linguagens de programação orientadas a objetos.

Primeiro você classifica e abstrai os elementos no sistema para proporcionar

uma certa ordem, e, ao fazer isto você define uma classe ;
Feita a definição da classe você pode criar objetos desta classe. (instanciar)
Vou citar aqui o exemplo clássico da planta de uma casa.

- A Classe seria um gabarito (como uma planta de uma casa)

- O objeto é concretização do gabarito (casas feitas a partir da mesma planta)

Quando levamos estes conceitos para as linguagens de programação nada se altera.

Existem alguns conceitos básicos que estão vinculados ao conceito de orientação a

objetos. São eles :
Herança
Encapsulamento
Polimorfismo
A herança permite implementar a funcionalidade a sua classe de tomar emprestado o
resto da estrutura e comportamento de classes de nível mais alto.

Pensemos na classe carro.

Esta classe define os comportamentos e atributos de um carro; E existem atributos
que serão comum a todos os carros.

As rodas e o motor são atributos comuns a qualquer carro. Já uma Ferrari possui
atributos que somente ela possui : o seu alto valor por exemplo.

A definição formal seria:

Herança é um mecanismo que permite que características comuns a diversas classes

sejam agrupadas em uma classe base, ou superclasse. A partir de uma classe base,
outras classes podem ser especificadas. Cada classe derivada ou subclasse apresenta
as características (estrutura e métodos) da classe base e acrescenta a elas o que for
definido de particularidade para ela

Encapsular significa "ocultar informações" ele define que cada objeto contém todos
os detalhes de implementação necessários sobre como ele funciona e oculta os
detalhes internos sobre como ele executa os serviços.

Quando você acelera um carro você esta enviando uma mensagem ao motor do carro
usando o acelerador e o carro sabe que tem que acelerar.

Você não precisa saber como é feita a aceleração no motor você apenas pisa fundo no
acelerador , a implementação de como é feita a aceleração esta encapsulada do
cliente.

Polimorfismo significa muitas formas , na orientação a objetos você pode enviar uma
mesma mensagem para diferentes objetos e fazê-los responder da maneira correta.
Você pode enviar a mensagem de dar marcha-ré para cada objeto semelhante a um
carro e cada um vai se comportar de maneira diferente para atender a sua
solicitação.

Uma definição mais formal diria:

"Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma
superclasse podem invocar métodos que têm a mesma identificação (assinatura) mas
comportamentos distintos, especializados para cada classe derivada, usando para
tanto uma referência a um objeto do tipo da superclasse"

Procurei ser o mais didático e simples possível .

Pensar em orientação a objetos realmente não é fácil e também não é a panacéia

universal.

Introdução a Orientação a Objetos

O termo orientação a objetos pressupõe uma organização de software em termos de coleção de
objetos discretos incorporando estrutura e comportamento próprios. Esta abordagem de
organização é essencialmente diferente do desenvolvimento tradicional de software, onde
estruturas de dados e rotinas são desenvolvidas de forma apenas fracamente acopladas.

Neste capítulo, as primeiras noções de orientação a objetos serão introduzidas. Esta breve visão
geral do paradigma permitirá entender melhor os conceitos associados à programação orientada
a objetos e, em particular, às construções da linguagem C ++.

Definições
Um objeto é uma entidade do mundo real que tem uma identidade. Objetos podem representar
entidades concretas (um arquivo no meu computador, uma bicicleta) ou entidades conceituais
(uma estratégia de jogo, uma política de escalonamento em um sistema operacional). Cada
objeto ter sua identidade significa que dois objetos são distintos mesmo que eles apresentem
exatamente as mesmas caraterísticas.

Embora objetos tenham existência própria no mundo real, em termos de linguagem de

programação um objeto necessita um mecanismo de identificação. Estaidentificação de
objeto deve ser única, uniforme e independente do conteúdo do objeto. Este é um dos
mecanismos que permite a criação de coleções de objetos, as quais são também objetos em si.

A estrutura de um objeto é representada em termos de atributos. O comportamento de um objeto

é representado pelo conjunto de operações que podem ser executadas sobre o objeto. Objetos
com a mesma estrutura e o mesmo comportamento são agrupados em classes. Uma classe é uma
abstração que descreve propriedades importantes para uma aplicação e simplesmente ignora o
resto.

Cada classe descreve um conjunto (possivelmente infinito) de objetos individuais. Cada objeto é
dito ser uma instância de uma classe. Assim, cada instância de uma classe tem seus próprios
valores para cada atributo, mas dividem os nomes dos atributos e métodos com as outras
instâncias da classe. Implicitamente, cada objeto contém uma referência para sua própria classe -
- em outras palavras, ele sabe o que ele é.
Polimorfismo significa que a mesma operação pode se comportar de forma diferente em classes
diferentes. Por exemplo, a operação move quando aplicada a uma janela de um sistema de
interfaces tem um comportamento distinto do que quando aplicada a uma peça de um jogo de
xadrez. Um método é uma implementação específica de uma operação para uma certa classe.

Polimorfismo também implica que uma operação de uma mesma classe pode ser implementada
por mais de um método. O usuário não precisa saber quantas implementações existem para uma
operação, ou explicitar qual método deve ser utilizado: a linguagem de programação deve ser
capaz de selecionar o método correto a partir do nome da operação, classe do objeto e
argumentos para a operação. Desta forma, novas classes podem ser adicionadas sem necessidade
de modificação de código já existente, pois cada classe apenas define os seus métodos e
atributos.

No mundo real, alguns objetos e classes podem ser descritos como casos especiais,
ou especializações, de outros objetos e classes. Por exemplo, a classe de computadores pessoais
com processador da linha 80x86 é uma especialização de computadores pessoais, que por sua
vez é uma especialização de computadores. Não é desejável que tudo que já foi descrito para
computadores tenha de ser repetido para computadores pessoais ou para computadores pessoais
com processador da linha 80x86.

Herança é o mecanismo do paradigma de orientação a objetos que permite compartilhar

atributos e operações entre classes baseada em um relacionamento hierárquico. Uma classe pode
ser definida de forma genérica e depois refinada sucessivamente em termos
de subclasses ou classes derivadas. Cada subclasse incorpora, or herda, todas as propriedades
de sua superclasse (ou classe base) e adiciona suas propriedades únicas e particulares. As
propriedades da classe base não precisam ser repetidas em cada classe derivada. Esta capacidade
de fatorar as propriedades comuns de diversas classes em uma superclasse pode reduzir
dramaticamente a repetição de código em um projeto ou programa, sendo uma das principais
vantagens da abordagem de orientação a objetos.

Conceitos Básicos
A abordagem de orientação a objetos favorece a aplicação de diversos conceitos considerados
fundamentais para o desenvolvimento de bons programas, tais como abstração e encapsulação.
Tais conceitos não são exclusivos desta abordagem, mas são suportados de forma melhor no
desenvolvimento orientado a objetos do que em outras metodologias.

Abstração
Abstração consiste de focalizar nos aspectos essenciais inerentes a uma entidade e ignorar
propriedades ``acidentais.'' Em termos de desenvolvimento de sistemas, isto significa
concentrar-se no que um objeto é e faz antes de se decidir como ele será implementado. O uso
de abstração preserva a liberdade para tomar decisões de desenvolvimento ou de implementação
apenas quando há um melhor entendimento do problema a ser resolvido.

Muitas linguagens de programação modernas suportam o conceito de abstração de dados;

porém, o uso de abstração juntamente com polimorfismo e herança, como suportado em
orientação a objetos, é um mecanismo muito mais poderoso.
O uso apropriado de abstração permite que um mesmo modelo conceitual (orientação a objetos)
seja utilizado para todas as fases de desenvolvimento de um sistema, desde sua análise até sua
documentação.

Encapsulação
Encapsulação, também referido como esconder informação, consiste em separar os aspectos
externos de um objeto, os quais são acessíveis a outros objetos, dos detalhes internos de
implementação do objeto, os quais permanecem escondidos dos outros objetos. O uso de
encapsulação evita que um programa torne-se tão interdependente que uma pequena mudança
tenha grandes efeitos colaterais.

O uso de encapsulação permite que a implementação de um objeto possa ser modificada sem
afetar as aplicações que usam este objeto. Motivos para modificar a implementação de um
objeto podem ser por exemplo melhoria de desempenho, correção de erros e mudança de
plataforma de execução.

Assim como abstração, o conceito de encapsulação não é exclusivo da abordagem de orientação

a objetos. Entretanto, a habilidade de se combinar estrutura de dados e comportamento em uma
única entidade torna a encapsulação mais elegante e mais poderosa do que em linguagens
convencionais que separam estruturas de dados e comportamento.

Compartilhamento
Técnicas de orientação a objetos promovem compartilhamento em diversos níveis distintos.
Herança de estrutura de dados e comportamento permite que estruturas comuns sejam
compartilhadas entre diversas classes derivadas similares sem redundância. O compartilhamento
de código usando herança é uma das grandes vantagens da orientação a objetos. Ainda mais
importante que a economia de código é a clareza conceitual de reconhecer que operações
diferentes são na verdade a mesma coisa, o que reduz o número de casos distintos que devem ser
entendidos e analisados.

O desenvolvimento orientado a objetos não apenas permite que a informação dentro de um

projeto seja compartilhada como também oferece a possibilidade de reaproveitar projetos e
código em projetos futuros. As ferramentas para alcançar este compartilhamento, tais como
abstração, encapsulação e herança, estão presentes na metodologia; uma estratégia de reuso
entre projetos é a definição de bibliotecas de elementos reusáveis. Entretanto, orientação a
objetos não é uma fórmula mágica para alcançar reusabilidade; para tanto, é preciso
planejamento e disciplina para pensar em termos genéricos, não voltados simplesmente para a
aplicação corrente.

O Modelo de Objetos
Um modelo de objetos busca capturar a estrutura estática de um sistema mostrando os objetos
existentes, seus relacionamentos, e atributos e operações que caracterizam cada classe de
objetos. É através do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos
ao invés de mecanismos tradicionais de desenvolvimento baseado em funcionalidades,
permitindo uma representação mais próxima do mundo real.
Uma vez que as principais definições e conceitos da abordagem de orientação a objetos estão
definidos, é possível introduzir o modelo de objetos que será adotado ao longo deste texto. O
modelo apresentado é um subconjunto do modelo OMT (Object Modeling Technique), proposto
por Rumbaugh e outros1.1. OMT também introduz uma representação diagramática para este
modelo, a qual será também apresentada aqui.

Objetos e Classes
Objeto é definido neste modelo como um conceito, abstração ou coisa com limites e significados
bem definidos para a aplicação em questão. Objetos têm dois propósitos: promover o
entendimento do mundo real e suportar uma base prática para uma implementação
computacional. Não existe uma maneira ``correta'' de decompor um problema em objetos; esta
decomposição depende do julgamento do projetista e da natureza do problema. Todos objetos
têm identidade própria e são distinguíveis.

Uma classe de objetos descreve um grupo de objetos com propriedades (atributos) similares,
comportamento (operações) similares, relacionamentos comuns com outros objetos e uma
semântica comum. Por exemplo, Pessoa e Companhia são classes de objetos. Cada pessoa tem
um nome e uma idade; estes seriam os atributos comuns da classe. Companhias também podem
ter os mesmos atributos nome e idade definidos. Entretanto, devido à distinção semântica elas
provavelmente estariam agrupados em outra classe que não Pessoa. Como se pode observar, o
agrupamento em classes não leva em conta apenas o compartilhamento de propriedades.

Todo objeto sabe a que classe ele pertence, ou seja, a classe de um objeto é um atributo
implícito do objeto. Este conceito é suportado na maior parte das linguagens de programação
orientada a objetos, tais como C ++.

OMT define dois tipos de diagramas de objetos, diagramas de classes e diagramas de instâncias.
Um diagrama de classe é um esquema, ou seja, um padrão ou gabarito que descreve as muitas
possíveis instâncias de dados. Um diagrama de instâncias descreve como um conjunto particular
de objetos está relacionado. Diagramas de instâncias são úteis para apresentar exemplos e
documentar casos de testes; diagramas de classes têm uso mais amplo. A Figura apresenta a
notação adotada para estes diagramas.

Atributos

Um atributo é um valor de dado assumido pelos objetos de uma classe. Nome, idade e peso são
exemplos de atributos de objetos Pessoa. Cor, peso e modelo são possíveis atributos de
objetos Carro. Cada atributo tem um valor para cada instância de objeto. Por exemplo, o
atributo idade tem valor ``29'' no objeto Pedro Y.Em outras palavras, Pedro Y tem 29 anos de
idade. Diferentes instâncias de objetos podem ter o mesmo valor para um dado atributo.

Cada nome de atributo é único para uma dada classe, mas não necessariamente único entre todas
as classes. Por exemplo, ambos Pessoa e Companhia podem ter um atributo chamado endereço.

No diagrama de classes, atributos são listados no segundo segmento da caixa que representa a
classe. O nome do atributo pode ser seguido por detalhes opcionais, tais como o tipo de dado
assumido e valor default. A Figura mostra esta representação.
 Figura: Representação diagramática de OMT para classes e objetos com atributos. Um diagrama de classe com atributos é
apresentado à esquerda. Um possível diagrama de instâncias com os respectivos valores é apresentado à direita.

Não se deve confundir identificadores internos de objetos com atributos do mundo real.
Identificadores de objetos são uma conveniência de implementação, e não têm nenhum
significado para o domínio da aplicação. Por exemplo, CIC e RG não são identificadores de
objetos, mas sim verdadeiros atributos do mundo real.

Operações e Métodos

Uma operação é uma função ou transformação que pode ser aplicada a ou por objetos em uma
classe. Por exemplo, abrir, salvar e imprimir são operações que podem ser aplicadas a objetos
da classe Arquivo. Todos objetos em uma classe compartilham as mesmas operações.

Toda operação tem um objeto-alvo como um argumento implícito. O comportamento de uma

operação depende da classe de seu alvo. Como um objeto ``sabe'' qual sua classe, é possível
escolher a implementação correta da operação. Além disto, outros argumentos (parâmetros)
podem ser necessários para uma operação.

Uma mesma operação pode se aplicar a diversas classes diferentes. Uma operação como esta é
dita ser polimórfica, ou seja, ela pode assumir distintas formas em classes diferentes.

Um método é a implementação de uma operação para uma classe. Por exemplo, a

operação imprimir pode ser implementada de forma distinta, dependendo se o arquivo a ser
impresso contém apenas texto ASCII, é um arquivo de um processador de texto ou binário.
Todos estes métodos executam a mesma operação -- imprimir o arquivo; porém, cada método
será implementado por um diferente código.

A assinatura de um método é dada pelo número e tipos de argumentos do método, assim como
por seu valor de retorno. Uma estratégia de desenvolvimento recomendável é manter assinaturas
coerentes para métodos implementando uma dada operação, assim como um comportamento
consistente entre as implementações.
Em termos de diagramas OMT, operações são listadas na terceira parte da caixa de uma classe.
Cada nome de operação pode ser seguida por detalhes opcionais, tais como lista de argumentos
e tipo de retorno. A lista de argumentos é apresentada entre parênteses após o nome da operação.
Uma lista de argumentos vazia indica que a operação não tem argumentos; da ausência da lista
de argumentos não se pode concluir nada. O tipo de resultado vem após a lista de argumentos,
sendo precedido por dois pontos (:). Caso a operação retorne resultado, este não deve ser
omitido -- esta é a forma de distinguí-la de operações que não retornam resultado. Exemplos de
representação de operações em OMT são apresentados na Figura .

Figura: Representação diagramática de OMT para classes com atributos e operações.

Ligações e Associações
Ligações e associações são os mecanismos para estabelecer relacionamentos entre objetos e
classes. Uma ligação é uma conexão física ou conceitual entre duas instâncias de objetos. Por
exemplo, Pedro Y trabalha-para Companhia W. Uma ligação é uma instância de uma
associação. Uma associação descreve um grupo de ligações com estrutura e semântica comuns,
tal como ``uma pessoa trabalha-para uma companhia.'' Uma associação descreve um conjunto
de ligações potenciais da mesma forma que uma classe descreve um conjunto de objetos
potenciais.

A notação de diagramas OMT para associação é uma linha conectando duas classes. Uma
ligação é representada como uma linha conectando objetos. Nomes de associações são
usualmente apresentada em itálico. Se entre um par de classes só existe uma única associação
cujo sentido deva ser óbvio, então o nome da associação pode ser omitido. A Figura apresenta
um exemplo de diagrama OMT com associações.
 Figura: Representação diagramática de OMT para associações entre classes (topo) e ligações entre objetos (abaixo).

Alguns atributos podem dizer respeito a associações, e não a classes. Para tais casos, OMT
introduz o conceito de atributo de ligação. Quando a associação tem ainda operações
associadas, então ela pode ser modelada como uma classe que está ``conectada'' à associação.
Um exemplo deste caso é apresentado na Figura .

Figura: Representação diagramática de OMT para associações entre classes com atributos. Neste caso, os atributos da
associação estão representados através de uma classe explícita, Autorização. O círculo preto no final da linha da associação
indica que mais de um objeto de uma classe podem estar associados a cada objeto da outra classe. Um círculo vazado indicaria
que possivelmente nenhum objeto poderia estar associado, ou seja, o conceito de associação opcional.

Agregação
Uma agregação é um relacionamento do tipo ``uma-parte-de,'' nos quais objetos representando
os componentes de alguma coisa são associados com objetos representando uma montagem. Por
exemplo, o texto de um documento pode ser visto como um conjunto de parágrafos, e cada
parágrafo é um conjunto de sentenças (Figura ).

Figura: Representação diagramática de OMT para agregação.

Agregação é uma forma de associação com alguma semântica adicional. Por exemplo, agregação
é transitiva: se A é parte de B e B é parte de C, então A é parte deC. Agregação também é anti-
simétrica: se A é parte de B, então B não é parte de A.

Generalização e Herança
Generalização e herança são abstrações poderosas para compartilhar similaridades entre classes e
ao mesmo tempo preservar suas diferenças.

Generalização é o relacionamento entre uma classe e um ou mais versões refinadas

(especializadas) desta classe. A classe sendo refinada é chamada de superclasse ou classe base,
enquanto que a versão refinada da classe é chamada uma subclasse ou classe derivada. Atributos
e operações comuns a um grupo de classes derivadas são colocadas como atributos e operações
da classe base, sendo compartilhados por cada classe derivada. Diz-se que cada classe
derivadaherda as características de sua classe base. Algumas vezes, generalização é chamada de
relacionamento is-a (é-um), porque cada instância de uma classe derivada é também uma
instância da classe base.

Generalização e herança são transitivas, isto é, podem ser recursivamente aplicadas a um número
arbitrário de níveis. Cada classe derivada não apenas herda todas as características de todos seus
ancestrais como também pode acrescentar seus atributos e operações específicos.

A Figura mostra a notação diagramática de OMT para representar generalização, um triângulo

com o vértice apontado para a classe base. Um discriminadorpode estar associado a cada
associação do tipo generalização; este é um atributo do tipo enumeração que indica qual a
propriedade de um objeto está sendo abstraída pelo relacionamento de generalização. Este
discriminador é simplesmente um nome para a base de generalização.
 Figura: Representação diagramática de OMT para generalização.

Uma classe derivada pode sobrepor1.2 uma característica de sua classe base definindo uma
característica própria com o mesmo nome. A característica local (da classe derivada) irá refinar e
substituir a característica da classe base. Uma característica pode ser sobreposta, por exemplo,
por questões de refinamento de especificação ou por questões de desempenho.

Entre as características que podem ser sobrepostas estão valores default de atributos e métodos
de operação. Uma boa estratégia de desenvolvimento não deve sobrepor uma característica de
forma inconsistente com a semântica da classe base.

Sugestões de desenvolvimento
Na construção de um modelo para uma aplicação, as seguintes sugestões devem ser observadas a
fim de se obter resultados claros e consistentes:

1. Não comece a construir um modelo de objetos simplesmente definindo classes,

associações e heranças. A primeira coisa a se fazer é entender o problema a ser resolvido.
2. Tente manter seu modelo simples. Evite complicações desnecessárias.
3. Escolha nomes cuidadosamente. Nomes são importantes e carregam conotações
poderosas. Nomes devem ser descritivos, claros e não deixar ambiguidades. A escolha de
bons nomes é um dos aspectos mais difíceis da modelagem.
4. Não ``enterre'' apontadores ou outras referências a objetos dentro de objetos como
atributos. Ao invés disto, modele estas referências como associações. Isto torna o modelo
mais claro e independente da implementação.
5. Tente evitar associações que envolvam três ou mais classes de objetos. Muitas vezes,
 estes tipos de associações podem ser decompostos em termos de associações binárias,
tornando o modelo mais claro.
6. Não transfira os atributos de ligação para dentro de uma das classes.
7. Tente evitar hierarquias de generalização muito profundas.
8. Não se surpreenda se o seu modelo necessitar várias revisões; isto é o normal.
9. Sempre documente seus modelos de objetos. O diagrama pode especificar a estrutura do
modelo, mas nem sempre é suficiente para descrever as razões por trás da definição do
modelo. Uma explicação escrita pode clarificar pontos tais como significado de nomes e
explicar a razão para cada classe e relacionamento.
10. Nem sempre todas as construções OMT são necessárias para descrever uma aplicação.
Use apenas aquelas que forem adequadas para o problema analisado.

Modelagem: do Problema ou do Negócio?

Dentro de um projeto de desenvolvimento de software, a MODELAGEM DO NEGÓCIO se caracteriza como uma das
atividades mais importantes. E por meio dela que as regras e os processos essências de um ambiente sistêmico
são caracterizados. Uma boa modelagem pode proporcionar a otimização do ambiente sistêmico, melhorando o
fluxo e a velocidade das informações. Algumas vezes, com a modelagem, é possível resolver o problema sem a
implementação do software. Neste post vou apresentar um case que valida esta afirmação.

Problema

Uma prefeitura de uma cidade de 60 mil habitantes deseja melhorar o processo de matriculas de alunos em suas
creches. A secretaria da educação detectou a seguinte falha: existem alunos matriculados em duas creches
durante o mesmo período letivo. Em determinados dias da semana o pai deixa o aluno na creche A e em outros
dias na creche B. Este procedimento diminui o número de vagas. Importante salientar o processo de matricula nas
creches não é centralizado.

A modelagem do problema, mapeada na figura abaixo, mostra que o processo de matricula não é centralizado.
Não existe uma comunicação entre as creches.

Solução proposta pela maioria dos analistas

Desenvolvimento de um software que possibilite a integração de todo o processo de matricula nas creches. As
informações sobre o processo estão disponíveis em um servidor de dados e as creches acessam este servidor (via
rede) e efetuam o matricula.

O projeto implica em:

adquirir o servidor e as estações de trabalho a serem utilizadas pelas creches;

proporcionar (via rede) a conexão de todas essas máquinas;
estabelecer um protocolo de segurança das informações;
implementar as regras contidas no protocolo.

Solução gerada com MODELAGEM DO NEGÓCIO

A MODELAGEM DO NEGÓCIO (vide figura abaixo) provê uma alternativa para resolver o problema.

Centralizar o processo de matricula na secretaria municipal de educação. Diariamente as creches informam, via
telefone, se existem vagas (pois o cancelamento da matricula pode ser feito diretamente na creche). A secretaria
possui uma planilha eletrônica com as informações de todos os alunos matriculados. Os pais ou responsáveis
efetuam a matricula na secretaria. A secretaria consulta a planilha. Se as informações do aluno estiverem
cadastradas na planilha, a matricula é recusada.

Este projeto não implica:

no desenvolvimento do software;
na aquisição do servidor e das estações de trabalho;
na conexão das máquinas;
no estabelecimento e implementação de um protocolo de comunicação.

Discussão

A MODELAGEM DO NEGÓCIO vai além da modelagem do problema. A modelagem do problema apresenta um

retrato da situação atual do processo. A MODELAGEM DO NEGÓCIO deve proporcionar uma alternativa altamente
eficaz para cliente, ela deve retratar a melhor forma de execução das regras que compõem o negócio.

Deixe de modelar problema e passe a MODELAR NEGÓCIO!

BABoK = REBoK? Conversando

sobre Análise e Modelagem de
Negócios
Análise de Negócios, BABoK, Engenharia de Requisitos, EPBE, IIBA, Modelagem
de Negócios, UML
Nada como um dia (agitadíssimo) depois de outro (não menos agitado). Ao reler o
artigo anterior, “O BABoK e a Disciplina „Enterprise Analysis‟“, reparei que posso
resumi-lo assim: O BABoK trata exclusivamente da macro-disciplina
Engenharia de Requisitos. Apesar do nome, a KA (Knowledge Area) Enterprise
Analsys (ou Análise Corporativa) trata exclusivamente daquilo que Karl Wiegers
chama de Requisitos de Negócio [1]. Trata bem e de maneira bem completa, diga-
se de passagem. Mas este fato torna o nome BABoK (Business Analysis Body of
Knowledge) meio enganador. Aquele conteúdo formaria um bom REBoK –
Requirements Engineering Body of Knowledge. Para a Análise de Negócio falta
uma metade: exatamente a Análise (e Modelagem) de Negócios!
Desconfio que a falta já é sentida pelos próprios autores e responsáveis pelo BoK.
Em uma das apresentações recentemente utilizadas na divulgação da profissão e
do BABoK, eles frisam:
Análise de negócios não é análise de requisitos de software. Analisar
um negócio é compreender:
Como a organização trabalha;
Qual a razão de sua existência;
Seus objetivos e metas;
Como ela busca esses objetivos; e
O que ela precisa mudar para melhor atender esses objetivos.
Para ajudar a definir uma solução para um problema de negócio.
Com certeza, alguém já fez a mesma cobrança que faço desde que conheci o
BABoK. Pena, mas a declaração acima (ainda) não está refletida naquele corpo de
conhecimentos. Não há no BABoK um conjunto de Tarefas e Técnicas que atenda
plenamente a lista acima, exceção feita ao terceiro item. Bom, como prometi
no artigo anterior, serei mais “construtivo”.
Antes de estudar as necessidades ou problemas de um negócio, é necessário
conhecê-lo, aprendê-lo. Uma maneira muito eficaz para se *aprender* um negócio é
a modelagem. Modelar é simplificar. Modelar é compilar apenas o que é essencial.
Indico (teimosamente) o uso da EPBE (Eriksson-Penker Business Extensions) para
a criação desses modelos por dois motivos principais: i) Ela é completa – me
permite cobrir todos os aspectos de um negócio, sua estrutura e sua dinâmica
(processos); e ii) A EPBE é uma extensão da UML (Unified Modeling Language),
uma linguagem madura, bem difundida e fácil de aprender. (Já apresentei a EPBE
em outra série de artigos).
Todo e qualquer negócio apresenta 4 *coisas* que precisamos aprender: Objetivos,
Recursos, Processos e Regras. Cada um deles pode merecer um ou mais modelos,
dependendo da criticidade do negócio ou do projeto em questão. A EPBE nos
oferece 4 visões, 4 dimensões – maneiras diferentes de *ver* o negócio: A visão do
Negócio propriamente dita; sua Estrutura; Processos e Comportamento. Não há
uma seqüência pré-fixada para o estudo. Como sempre, depende do negócio e do
projeto. Mas, mesmo em empreendimentos muito simples, não abro mão de um
enxuto mapa de processos e do diagrama de processos (ou “linha de montagem“)
um pouco mais detalhado. Usando uma boa ferramenta CASE [2], e não meus
rabiscos, obtemos automaticamente outros modelos, como a estrutura de recursos,
objetivos e metas (ou mesmo um balanced scorecard).
Ao estudar os processos, vendo as atividades e tarefas que os formam e toda a
estrutura (departamentos e outros recursos) envolvida em sua execução,
ganhamos uma visão mais nítida do “terreno que estamos pisando”. Se há um
projeto, existem Requisitos de Negócio. São os objetivos (um dos 4 elementos
básicos apresentados acima, lembra-se?), as necessidades ou problemas que
devemos sanar. São os primeiros requisitos que conhecemos. Na maioria das
vezes, bem antes do projeto ser iniciado. Mesmo que sejam mais críticos e
essencias para o sucesso do projeto, esses requisitos são tratados da mesma
forma – acolhidos em uma mesma estrutura. Destaquei este ponto para mostrar
que Análise e Modelagem de Negócios e a Engenharia de Requisitos são
atividades que ocorrem de maneira simultânea, e não sequencial. Nem quem
mergulha em “cascatas” conseguiria tratá-las como fases distintas de um projeto –
são naturalmente indissociáveis, “gêmeas siamesas”.
Processos Envelhecem
O que acontece quando um recurso de uma empresa se torna obsoleto? Ele é
trocado, certo? Se for um computador ou um caminhão, compra-se um novo. Se for
uma pessoa, aposenta-se ou mostra-lhe o bilhetinho azul (ou cartão vermelho,
como queira). Mas, e quando um processo de negócio envelhece? O que
acontece? As empresas costumam remendá-los e redesenhá-los. Trocas radicais
só ocorrem mediante a implementação arbitrária de um pacote de melhores
práticas também conhecido como ERP. Mas, mesmo assim, em curto espaço de
tempo, voltam os remendos e redesenhos. O mundo não pára.

O envelhecimento de processos, assim como o nosso, vem com más notícias. Saca
aquela dorzinha na coluna que nunca tivemos? Bom, é por aí. E aqui entramos num
ponto relativamente polêmico do trabalho dos Analistas de Negócios (AN‟s). É mal
traçada a linha que os separa daqueles tradicionais Consultores de Negócios. Há
quem diga que um AN não deve “se meter” com os problemas do negócio. Oras, o
que justificaria tamanha “vista grossa”?

É claro que, quando em projetos para desenvolvimento ou implantação de

sistemas, o foco do AN não é o redesenho (ou reengenharia) de processos de
negócio. Mas isso não significa que ele deva ignorar sintomas e doenças que
porventura encontre durante seus estudos. Se ele insistir em levar para a solução
aquele processo e suas pequenas dores, levará também maiores riscos e chances
de mudanças. É exatamente por isso que, ao contrário do RUP, gosto de chamar
esta disciplina de Análise e Modelagem de Negócios. Soarei idiota, mas preciso
reforçar: é o Analista de Negócios quem executa a Análise de Negócios! E analisar,
definitivamente, não se resume ao desenho de belos modelos.
Portanto, a grande e grave deficiência do BABoK é o fato deste ignorar por
completo este estudo, a análise e modelagem de negócios. Acho pouco provável
que todo esse “chororô”, que não é só meu, gere alguma mudança significativa na
versão 2.0 que está em vias de ser publicada. Resta torcer para que, ao contrário
do que ocorre em outras instituições similares, eles não se apeguem de forma
intransigente à estrutura atual daquele corpo de conhecimentos. Seria fatal.

Outros Corpos
Como eu disse lá em cima, foi uma semana bem agitada. Em nosso grupo de
discussão, parcialmente restrito aos participantes de meus eventos, surgiu um
conversa meio “subversiva”: elaborar o que o amigo Jefferson chamou de “BABoK
Apócrifo”! Acho que (ainda) não é o caso, mas um fruto imediato aquela discussão
toda já gerou: nascerá (muito) em breve um Fórum que tratará exclusivamente do
BABoK e da profissão AN. Ao contrário do grupo, acho que o Fórum será público.
Acho. A turma decidirá.

[Encerramento c/ merchan]: Acontece na próxima quinta-feira (24/abr), em

Sampa, a2ª edição da oficina Análise e Modelagem de Negócios. É um evento de
um dia só, mas consigo mostrar nele tudo aquilo que, na minha opinião, foi
ignorado no BABoK. Nesta página você tem uma visão geral do programa. É
extenso e tem vários exercícios. Mas nada que a gente não consiga conversar em 1
dia.
4. Análise e Especificação de Requisitos
Os objetivos deste capítulo são:

Definir o que são requisitos de software

Introduzir os objetivos da Engenharia de Requisitos
Apresentar técnicas de comunicação para obter informações dos clientes e usuários
Apresentar técnicas para descrever o domínio, usuários e tarefas.
Especificar requisitos funcionais utilizando Casos de Uso
Especificar requisitos não funcionais

4.1 Engenharia de Requisitos

Vimos que o software é parte de um sistema computacional mais abrangente e que a Análise
de Sistemas é a atividade de identificar os problemas do domínio, apresentar alternativas de
soluções e o estudo da viabilidade de cada uma delas. Uma vez que se tenha feito a análise do
sistema computacional, e delimitado o escopo do software, os requisitos do software devem
ser analisados e especificados.

A análise e especificação de requisitos de software envolve as atividades de determinar os

objetivos de um software e as restrições associadas a ele. Ela deve também estabelecer o
relacionamento entre estes objetivos e restrições e a especificação precisa do software.

A análise e especificação dos requisitos de software deve ser vista como uma sub-atividade da
análise de sistemas. Normalmente ela é iniciada juntamente com a análise do sistema, podendo
se estender após a elaboração do documento de especificação do sistema e do planejamento do
desenvolvimento, quando serão refinados os requisitos do software.

Análise e especificação são atividades inter-dependentes e devem ser realizadas conjuntamente.

A análise é o processo de observação e levantamento dos elementos do domínio no qual o
sistema será introduzido. Deve-se identificar as pessoas, atividades, informações do domínio
para que se possa decidir o que deverá ser informatizado ou não. Pessoas e as atividades que não
serão informatizadas deverão ser consideradas entidades externas ao software.

A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir

daquilo que foi analisado. Ela apresenta a solução de como os problemas levantados na análise
serão resolvidos pelo software do sistema computacional. Visa descrever de maneira sistemática
quais as propriedades funcionais são necessárias para resolver o problema do domínio. A
especificação é também a forma de comunicação sistemática entre analistas e projetistas do
software.

O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os
critérios de validação que serão utilizados para que se possa avaliar se o sistema cumpre o que
foi definido.
4.1.1 O que são requisitos?
Como sistemas computacionais são construídos para terem utilidade no mundo real. Modelar
uma parte do mundo real, o domínio de aplicação é uma atividade extremamente importante
para se compreender a necessidade e a importância do sistema a ser construído e definir os
requisitos que tornam o sistema útil.

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que
definem as diversas propriedades do sistema. Os requisitos de software são, obviamente,
aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que
o software deve possuir (1) para que o usuário possa resolver um problema ou atingir um
objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros
componentes do sistema.

Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-

funcionais. Os requisitos funcionais são a descrição das diversas funções que clientes e
usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do
software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo
sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou
externos ao sistema.

São exemplos de requisitos funcionais:

"o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais
com pessoal".
"o software deve emitir relatórios de compras a cada quinze dias"
"os usuários devem poder obter o número de aprovações, reprovações e trancamentos
em todas as disciplinas por um determinado período de tempo.

A especificação de um requisito funcional deve determinar o que se espera que o software

faça, sem a preocupação de como ele faz. É importante diferenciar a atividade de especificar
requisitos da atividade de especificação que ocorre durante o design do software. No design
do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para
satisfazer àquilo que os usuários querem.

Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade,

usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de
maneira informal, de maneira controversa (por exemplo, o gerente quer segurança mas os
usuários querem facilidade de uso) e são difíceis de validar.

São exemplos de requisitos não-funcionais:

"a base de dados deve ser protegida para acesso apenas de usuários autorizados".
"o tempo de resposta do sistema não deve ultrapassar 30 segundo".
"o software deve ser operacionalizado no sistema Linux"
"o tempo de desenvolvimento não deve ultrapassar seis meses".
A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida que o
tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre
os outros. Por exemplo, o requisito de que o software deve ter grande portabilidade (por
exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja
satisfeito (programas em Java são, em geral, mais lentos).
4.1.2 A Engenharia de Requisitos
Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são
muito difíceis de ser controlados. Principalmente se considerarmos que algumas decisões de
design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento.
Por exemplo, a decisão de implementar em Java pode ser decidida apenas após o design da
arquitetura. Desta forma, os requisitos precisam ser gerenciados durante todo o
desenvolvimento.

A importância e complexidade desta atividade levou ao surgimento, no início dos anos 90,
da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que o processo de
definir os requisitos de software é uma atividade extremamente importante e independente das
outras atividades da engenharia de software. Ela requer fundamentação e processos próprios, e
que devem ser planejados e gerenciados ao longo de todo o ciclo de vida.

Os objetivos da Engenharia de Requisitos podem ser categorizados em três grupos principais

[Zave]:

Investigação de objetivos, funções e restrições de uma aplicação de software

o Ultrapassar as barreiras de comunicação
o Gerar estratégias para converter objetivos vagos em propriedades ou restrições
específicas
o Compreender prioridades e graus de satisfação
o Associar requisitos com os vários agentes do domínio
o Estimar custos, riscos e cronogramas
o Assegurar completude
Especificação do software
o Integrar representações e visões múltiplas
o Avaliar estratégias de soluções alternativas que satisfaçam os requisitos
o Obter uma especificação completa, consistente e não ambígua
o Validar a especificação - verificar que ela satisfaz aos requisitos
o Obter especificações que sejam apropriadas para as atividades de design e
implementação
Gerenciamento da evolução e das famílias do software
o Reutilização de requisitos durante o processo de evolução
o Reutilização de requisitos no desenvolvimento de software similares
o Reconstrução de requisitos

A Engenharia de Requisitos deve envolver a documentação das funções, do desempenho,

interfaces externas e internas e atributos de qualidade do Software.
Esta área é inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrição de
observações do mundo real através de notações apropriadas.

Os benefícios da Engenharia de Requisitos são:

Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito e

quais os critérios de aceitação do sistema.
Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e
equipamentos)
Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
Atingir os objetivos com o mínimo de desperdício

Uma boa especificação de requisitos deve ser:

Clara e não-ambígua
Completa
Correta
Compreensível
Consistente
Concisa
Confiável

(Veja mais em Dorfman, Merlin - Requirements Engineering)

4.1.3 Técnicas de levantamento de requisitos
Um dos objetivos da Engenharia de Requisitos é ultrapassar barreiras de comunicação entre os
clientes e usuários e os analistas para que os requisitos possam capturados e modelados
corretamente

Dentre as técnicas mais importantes para a comunicação podemos citar três:

Entrevistas
Observação in loco
Encontros

Estas três técnicas são complementares e podem todas ser usadas numa mesma análise de
requisitos. A entrevista é normalmente a primeira técnica utilizada. Analistas entrevistam
clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista
deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas
seções de entrevistas podem ser marcadas.

Na observação in loco os analista devem estar inseridos na rotina de trabalho da organização

tentando entender e descrever as principais atividades que são realizadas. Na observação devem
ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários,
quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser
complementada com entrevistas específicas com os futuros usuários.
Os encontros são reuniões envolvendo analistas, clientes e usuários destinadas exclusivamente
ao levantamento de informações, descrição dos problemas atuais e de metas futuras. Os
encontros devem ser realizados em um local neutro (fora da organização) e normalmente duram
poucos alguns dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas
em paineis na sala de encontro para que possam ser analisadas e validadas pelos clientes e
usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os
requisitos analisados.

4.1.4 Modelos de documentos de especificação de requisitos

O resultado final da análise e especificação de requisitos e das outras atividades da fase de
definção devem ser apresentados aos clientes para que eles possam validá-lo. Este documento
oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser
desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento
(design e programação) serão validadas.

Cada desenvolvedor utiliza um modelo específico para elaborar este documento. A sua estrutura
muitas vezes depende do método que está sendo utilizado. Em linhas gerais este modelo deve
ser basicamente textual, utilizando o mínimo de termos técnicos, e ilustrados como modelos
gráficos que demonstrem mais claramente a visão que os analistas tiveram dos problemas e dos
requisitos para o futuro sistema.

Vamos apresentar a seguir dois modelos de documentos encontrados na literatura. Estes

modelos descrevem não apenas a especificação dos requisitos, mas os resultados do estudo de
viabilidade e o processo de desenvolvimento.

Pressman apresenta o seguinte documento de especificação de requisitos de software:

I. Introdução

1. Referências do Sistema
2. Descrição Geral
3. Restrições de projeto do software

II. Descrição da Informação

1. Representação do fluxo de informação

a. Fluxo de Dados
b. Fluxo de Controle

2. Representação do conteúdo de informação

3. Descrição da interface com o sistema

III Descrição Funcional

1. Divisão funcional em partições

2. Descrição funcional
 a. Narativas
b. Restrições/limitações
c. Exigências de desempenho
d. Restrições de projeto
e. Diagramas de apoio

3. Descrição do controle

a. Especificação do controle
b. Restrições de projeto

IV. Descrição Comportamental

1. Estados do Sistema
2. Eventos e ações

V. Critérios de Validação

1. Limites de desempenho
2. Classes de testes
3. Reação esperada do software
4. Considerações especiais

VI. Bibliografia
VII Apêndice

Uma proposta alternativa é a de Farley. De acordo com ele, um documento de especificação de

requisitos deve possui as seguintes seções:

Visão geral do produto e Sumário

Ambientes de desenvolvimento, operação e manutenção
Interfaces Externas e Fluxo de Dados
Requisitos Funcionais
Requisitos de Desempenho
Tratamento de Exceções
Prioridades de Implementação
Antecipação de mudanças e extensões
Dicas e diretrizes de Design
Critérios de aceitação
Índice Remissivo
Glossário

4.2 Especificando Requisitos utilizando Casos de Uso

Após saber quais as tarefas associadas a cada papel de usuário, é hora de elaborar os casos de
uso (use cases) que permitem definir as funções de aplicação que o sistema deverá oferecer
para o usuário. Os casos de uso podem ser utilizadas durante a análise e especificação dos
requisitos para descrever a funcionalidade do sistema.

Os casos de uso foram definidos como parte da metodologia de Jacobson: Object-oriented

Analysis and Design - The User Case Driven Approach. A linguagem de
modelagem UML (Unified Modeling Language) apresenta notações para a representação de
casos de uso.

Um caso de uso especifica o comportamento do sistema a ser desenvolvido sem, no entanto,

especificar com este comportamento será implementado. Os comportamentos descrevem as
funções da aplicação que caracterizam a funcionalidade do sistema. Um caso de uso representa
o que o sistema faz e não como o sistema faz, proporcionando uma visão externa e não interna
do sistema.

Cada caso de uso define um requisito funcional do sistema. Por exemplo, num sistema
bancário, consulta de saldo, empréstimos e saques de dinheiro são exemplos de casos de uso.

O caso de uso descreve um conjunto de seqüências de ações que o sistema desempenha para
produzir um resultado esperado pelo usuário. Cada seqüência representa a interação de entidades
externas e o sistema. Estas entidades são chamadas de atores e que podem ser usuários ou
outros sistemas. No caso de usuários, um ator representa na verdade uma função de usuários.

Os casos de uso podem ser compostos por outros casos de uso mais específicos. Esta estrutura
deve estar em conformidade com o particionamento do sistema em sub-sistemas. Desta forma
tanto é possível descrever casos de uso que aplicam-se ao sistema global, quanto casos que são
específicos para cada uma das partes do sistema.

Casos de uso também podem ser especializados, por exemplo uma consulta pode ser
especializada em consulta de saldo e consulta de extrato, que por sua vez podem ser
especializados, cada um , em consultas a conta-corrente ou a conta-poupança.

Ao definir os requisitos funcionais, o caso de uso define o comportamento, as respostas

esperadas e os casos de testes que devem validar a implementação do sistema.

4.2.1 A representação de casos de uso usando UML

A notação UML será utilizada neste curso como linguagem de especificação para a maioria das
atividades do ciclo de vida do sistema. A partir de agora vamos introduzir esta notação
necessária para representar casos de uso. Ao longo do curso outros aspectos da linguagem
serão introduzidos.

Um caso de uso é representado por uma elipse. Cada caso de uso disntigue-se de um outro por
um nome que normalmente é um verbo seguido do seu objeto.

Um ator que pode ser uma ou mais função de usuário é representado por uma figura simples de
um indivíduo (um boneco-de-palitos).

Os atores são conectados a casos de uso por uma associação representadas por uma linha.
O comportamento associado a cada caso de uso pode ser descrito como um cenário. Cada
cenário descreve textualmente o fluxo de eventos ou seqüência que caracteriza o comportamento
do ator e as respostas do sistema. Um cenário é uma instância do caso de uso.

Por exemplo num caixa eletrônico bancário, o caso de uso validar cliente pode ser descrito pelo
seguinte cenário:

Fluxo de eventos principal: O casos de uso inicia quando o sistema solicita ao

cliente (do banco) a sua senha. O cliente fornece os números através do teclado.
O cliente confirma a senha pressionando a tecla entre. O sistema checa este
número e verifica se ele é válido.

Fluxo de evento excepcional: O cliente pode cancelar a transação a qualquer

momento pressionando o botão cancele, reiniciando o caso de uso. Não é feita
nenhuma mudança na conta do usuário.

Fluxo de evento excepcional: O cliente pode corrigir a senha a qualquer momento

antes de confirmar com a tecla entre.

Fluxo de evento excepcional: Se o cliente fornece um número de senha inválido o

caso de uso é reiniciado. Se isto acontecer três vezes seguidas, o sistema cancela o
caso de uso e bloqueia por até uma hora.

Os casos de uso também podem ser descritos de maneira mais estruturada e formal, por
exemplo, usando pré- e pós-condições. Diversas técnicas e notações para especificações
formais permitem descrever o comportamento da funções da aplicação em termos de pré- e
pós-condições. As pré-condições estabelecem as condições que devem estar satisfeita antes
que a função seja executada pelo sistema, enquanto que as pós-condições determinam o que
deve ser válido ao final da execução. Estes estados iniciais e finais do sistema descrevem o
comportamento independente de como será implementado, isto é, quais os algoritmos,
estrutura de dados e linguagem de programação a serem utilizados. As especificações formais
não são abordadas neste curso.

Os casos de uso podem ainda ser descritos através de outros diagramas UML. Os diagramas de
atividades descrevem os diversos estados e as transições entre cada um deles. Os diagramas de
interação permitem descrever as interações entre o ator e o componente do sistema que
implementa o caso de uso. Estes diagramas serão estudados mais adiante no capítulo 5.
Veja o exemplo acima especificado através de diagramas de estados e de atividades na seção
5.2.7.

4.2.3 Diagrama de Casos de Uso em UML

A UML permite elaborar diversos diagramas para visualização, especificação, construção e
documentação de diversas partes do sistema em diversas etapas do ciclo de vida. Existem
cinco tipos de diagramas que permitem modelar aspectos dinâmicos do sistema através da
UML. O diagrama de casos de uso é um destes diagramas e pode ser utilizado para
visualização, especificação e documentação de requisitos do sistema.
A especificação dos requisitos visa descrever o que o sistema deve fazer para satisfazer as metas
dos usuários (requisitos funcionais) e quais outras propriedades é desejável que o sistema possua
(requisitos não-funcionais). Vimos que casos de usos, individualmente, descrevem requisitos
funcionais. Acrescentandos Notas aos diagramas de casos de uso podemos especificar também
os requisitos não-funcionais.

Um diagrama de casos de uso contém:

Casos de Uso
Atores
Relacionamentos de dependência, generalização e associações

Podem ser acrescentadas Notas com em qualquer outro diagrama UML.

Para modelar os requisitos de software de um sistema podemos seguir as seguintes regras.

Estabeleça o contexto do sistema identificando os atores (usuários e sistemas externos)

associados a ele.
Para cada ator, considere o comportamento que cada um deles espera ou requer que o
sistema possua, para que as suas metas sejam satisfeitas.
Considere cada um destes comportamentos esperados como casos de uso, dando
nomes para cada um deles.
Analise os casos de uso tentando identificar comportamentos comuns a mais de um
deles. Defina esta parte comum como caso de uso genérico, estabelecendo um
relacionamento de generalização. Tente identificar outros relacionamentos, como a
dependência entre casos de uso que incluem o comportamento de outros .
Modele estes casos de uso, atores e seus relacionamentos em diagramas de casos de
uso.
Complemente estes casos de uso com notas que descrevam requisitos não-funcionais.

Além destas regras básicas, algumas dicas ajudam a construir diagramas mais claros.

Dê nomes que comuniquem o seu propósito.

 Quando existirem relacionamentos, distribua os casos de uso de maneira a minimizar os
cruzamentos de linhas.
Organize os elementos espacialmente de maneira que aqueles que descrevem
comportamento associados fiquem mais próximos.
Use notas para chamar a atenção de características importantes - as notas não são
apenas para os requisitos não funcionais.
Não complique o diagrama, coloque apenas o que é essencial para descrever os
requisitos. O diagrama deve ser simples sem deixar de mostrar o que é relevante.

4.3 Técnicas complementares para análise de requisitos

Definir casos a partir do nada pode ser bastante difícil. Antes de começar a pensar em casos de
uso o analista pode descrever cenários com situações do domínio. Estes cenários contêm
informações que podem ser extraídas mais detalhadamente com o objetivo de detalhar os
cenários. Além dos cenários, a análise do perfil dos usuário e das tarefas que eles executam
permitem um maior conhecimento do domínio, possibilitando uma melhor especificação dos
requisitos.

4.3.1 Cenários
Do ponto de vista de usabilidade, o desenvolvimento de um novo sistema implica na
transformação das tarefas e práticas atuais dos usuários e da organização. Conhecer a situação
atual e antecipar o impacto que um novo sistema deve ter é fundamental para o seu sucesso.
Isso ocorre porque quando se introduz novas tecnologias, parte do contexto de tarefa de uma
organização é alterado. Nessa reengenharia, novas tarefas e práticas são incorporadas
enquanto que outras são eliminadas.

O levantamento de informações sobre as tarefas e os usuários pode ser melhor realizado quando
os analistas procuram descrever situações do processo de trabalho. Os métodos baseados
em cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o
levantamento de informações, a identificação de problemas e a antecipação das soluções.
Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais
e as possibilidades que podem surgir.

Os cenários têm como foco as atividades que as pessoas realizam nas organizações
possibilitando uma perspectiva mais ampla dos problemas atuais onde o sistema será inserido,
explicando porque ele é necessário. Eles proporcionam um desenvolvimento orientado a tarefas
possibilitando maior usabilidade do sistema.

Não é objetivo dos cenários oferecer uma descrição precisa, mas provocar a discussão e
estimular novos questionamentos. eles permitem também documentar o levantamento de
informações a respeito dos problemas atuais, possíveis eventos, oportunidades de ações e riscos.

Por sua simplicidade, cenários são um meio de representação de fácil compreensão para os
clientes e usuários envolvidos (muitas vezes de formação bastante heterogênea) que podem
avaliar, criticar e fazer sugestões, proporcionando a reorganização de componentes e tarefas do
domínio. Cenários oferecem um "meio-intermediário" entre a realidade e os modelos que serão
especificados possibilitando que clientes, usuários e desenvolvedores participem do
levantamento das informações e especificação dos requisitos. Em resumo, os cenários permitem
compreensão dos problemas atuais pelos analistas e antecipação da situação futura pelo clientes
e desenvolvedores.

Elaborando Cenários
Como toda atividade de análise e especificação de requisitos, a descrição do domínio através
de cenários requer técnicas de comunicação e modelagem.

A descrição de cenários deve ser apoiada pelas três técnicas de comunicação vistas
anteriormente. Antes de descrever os cenários, os analistas devem entrevistar clientes para
entender os problemas e requisitos iniciais. A entrevista com usuários permite que cada um
descreva as suas tarefas e os problemas associados a cada uma delas. A observação direta in
loco é fundamental para que os analistas possam descrever a situação de uso como ela realmente
vem ocorrendo na prática.

Após a elaboração dos cenários, clientes, usuários e analistas podem participar

de encontros para que possam discutir cada um destes cenários. Eles podem ser afixados em
quadros na parede onde os participantes possa analisá-los e fazer comentários, possivelmente
afixando pequenos pedaços de papel a cada uma das cenas.

Cenários podem ser descritos em narrativas textuais ou através de storyboards. As narrativas

textuais podem ser descritas livremente, identificando os agentes e as ações que eles participam.
É possível utilizar notações para descrever roteiros de cinemas ou notações mais precisas como
aquelas utilizadas pela Inteligência Artificial para representação de conhecimento.

Uma técnica que está bastante relacionada com cenários, por permitir descrever situações de
uso, é o storyboarding. Essa técnica envolve a descrição através de quadros com imagens que
ilustram as situações do domínio. Cada quadro deve apresentar a cena que descreve a situação,
os atores e as ações que cada um deve desempenhar. Abaixo de cada quadro devem estar
descritas ações que os atores desempenham. Os storyboards são bastante utilizados em cinemas
como forma de comunicação entre roteiristas, diretores, atores e técnicos.

Existem ferramentas computacionais que podem ser utilizadas para a descrição de cenários
como o Scenario's Browser [Rosson 99].

Exemplos de cenários
Como exemplo vamos considerar o domínio de uma locadora de fitas de vídeo.

Cena 1: Cliente procura uma fita com uma certa atriz

Agentes: Cliente, Atendente, Balconista
Ações:

Cliente entra na loja e dirige-se até a atendente.

Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Atendente: - Algum específico?
Cliente: - Não, mas que não seja policial ou ação.
Atendente: Você sabe o nome dela?
Cliente: Não.
A atendente pergunta à balconista.
 Atendente: - Você sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. É um nome bem complicado. Só sei que começa com G e o sobrenome é
algo parecido com Paltrow.
Cliente: É isto mesmo.
A atendente então procura no fichário de atrizes as que começam com G. Não encontra
nenhum nome parecido com o que a balconista falou. Ela então lembra-se de consultar
uma revista especializada com os ganhadores do Oscar 99 e lá descobre o nome correto
da atriz. Entretanto, não existe realmente ficha alguma com os filmes estrelados por
esta atriz. O fichário está desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime
Perfeito e Seven e mostra-os ao cliente. O cliente recusa-se dizendo que não gosta do
gênero destes filmes e pergunta pelo filme vencedor do Oscar.
A atendente responde: - Shakespeare Apaixonado? Ainda não saiu em vídeo.

Cena 2: O cliente procura por filmes de um certo gênero

Agentes: Cliente, Atendente, Balconista
Ações:

Cliente: - Eu gostaria de comprar um filme de ação.

Atendente: - Nós apenas alugamos.
Cliente: - Tudo bem. Então, por favor, me dê algumas dicas de filmes de ação.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dúvida se já assistiu
outros três. Ele também pergunta à atendente se os outros dois filmes são bons. Após
conversar durante alguns minutos com a atendente que entende muito do gênero,
decide ficar com seis fitas. A atendente encaminha o cliente à balconista para calcular o
valor da locação e o prazo de devolução. Após consultar as tabelas de preços e prazos, a
balconista apresenta três planos de pagamento.
Balconista: - Se você devolver em um dia, paga apenas R$ 6,00. Se devolver em seis dias
paga R$ 12,00 e se devolver em uma semana paga R$ 15,00. Após este prazo paga mais
R$ 2,00 por fita, por dia.

Cena 3: Cliente procura por filme usando o sistema de consulta

Agentes: Cliente e Sistema de Consulta
Ações:

João gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e,
chegando lá, utiliza um sistema de consulta. Ele não lembra o título nem o diretor, mas
sabe que se passava na guerra do Vietnã e lembra bastante da trilha sonora. Utilizando o
sistema ele solicita as opções de filmes de guerra. Os sistema oferece a ele as
 possibilidades de escolher os filmes por local da guerra ou por época. João escolhe a sua
opção (guerra) e obtem uma lista com dezenas de filmes sobre o vietnam. Ele pode
organizar esta lista, por diretor, atores e título. Na tela do sistema aparecem a ilustração
com o cartaz de divulgação do filme e uma opção para ele visualizar o trailler. O
sistema, entretanto, não possibilita ele ouvir a trilha sonora.

Após analisar algumas opções ele finalmente encontra o filme desejado, mas uma
informação na tela do sistema indica que o filme está alugado. João quer saber quando o
filme será devolvido, mas esta informação não consta no sistema. Ele entretanto pode
reservar e o sistema enviará para ele um e-mail avisando quando o filme estiver
disponível. Ele sai da loja pensando "Que tempo perdido. Seria melhor que eu pudesse
consultar o sistema de casa".

4.3.2 Questionamento Sistemático

A descrição de informações do domínio através de narrativas só é efetivamente realizada se o

processo de compreensão por parte dos analistas e projetista for realizado de maneira sistemática
[J. Carroll et al. 94]. O questionamento sistemático é uma técnica que permite ao analista
obter, a partir dos cenários, uma rede de proposições na qual identifica-se agentes (atores),
ações (processos de casos de uso), e objetos (informações).

O questionamento sistemático uma técnica psico-linguística que permite a psicólogos e

lingüistas examinar o conteúdo e a estrutura de informações contidas numa narrativa. Uma
narrativa é um sumário de um conjunto de eventos e ações envolvendo agentes e objetos do
mundo. Nem todas as informações integrantes do contexto são passadas através da narrativa.
Muitas dessas informações são inferidas do conhecimento cultural de cada indivíduo. Outras,
entretanto, precisam ser obtidas diretamente na fonte, isto é, junto ao autor da narrativa. Essa
técnica foi desenvolvida para se entender melhor o processo de compreensão de estórias em
narrativas. O objetivo é compreender tudo o que envolve o contexto daquilo que está sendo
passado na narrativa.

Aplicando essa técnica no processo de análise de domínios, os especialistas devem descrever em

narrativas seu conhecimento do domínio. Entretanto, esse conhecimento é muito mais
abrangente. O questionamento sistemático permite obter todo o conhecimento que está além do
que foi comunicado na narrativa. Assim, analistas e projetista podem utilizar essa técnica para
adquirir mais eficazmente conhecimento sobre o domínio e inferir objetos e interações que não
estão descritos na narrativa. Isto ocorre usando-se cada sentença ou afirmação da narrativa como
ponto de entrada na complexidade do problema.

Nessa técnica, cada questão é uma ponte entre uma idéia e outra. Uma resposta a uma questão
sobre um componente da narrativa revela outras conexões que são críticas para o seu
entendimento. Realizando, sistematica e exaustivamente muitos tipos de questões sobre
componentes da narrativa e iterativamente fazendo perguntas sobre as respostas geradas, o
analista elabora um mapa conceitual (rede de proposições) que representa as estruturas do
conhecimento do domínio.

Os passos do método consistem de:

 1. Geração do cenário - as narrativas que compõe o cenário devem ser decritas pelo
especialista no domínio. O analista pode motivá-lo fazendo perguntas como num
processo convencional de entrevista (questões de elicitação do cenário).
2. Elaboração da rede de proposições - as narrativas devem ser simplificadas e
expressas através de proposições.
3. Análise - a partir das proposições pode-se determinar as tarefas (ações e objetos)
e usuários (agentes das ações).
4. Questionamento sistemático - novas proposições podem ser elaboradas através de
questões que são feitas sobre elementos das proposições anteriores, num processo
iterativo.

Nos passos iniciais obtem-se informações sobre agentes, interações e objetos abstratos do
domínio. Usando a técnica, pode-se chegar a um conhecimento mais profundo do domínio que
permite aos analistas e projetista a elaboração de modelos funcionais do sistema.

Exemplo
Considere o seguinte cenário sobre um caixa eletrônico.
Questão de elicitação do cenário:

Como posso sacar R$ 100,00 do caixa eletrônico?

Cenário:

Primeiro ponha o seu cartão do banco no caixa eletrônico, digite a sua senha e pressione
o botão "saque rápido". Depois pegue o dinheiro.

As duas sentenças do cenário acima contém quatro proposições:

CLIENTE -- põe -- CARTÃO

CLIENTE -- digita -- SENHA
CLIENTE -- pressiona -- BOTÃO-DE-SAQUE-RÁPIDO
CLIENTE -- pega -- DINHEIRO

A partir dessas proposições, o analista determina que o cartão e o cliente são agentes de
ações. Numa análise voltada para a elicitação de requisitos da interação, seria determinado
como usuário do sistema, o cliente. A ações são portanto: digita, pressiona e pega. São objetos
da interação a senha, o botão e o dinheiro. Outros objetos são o caixa eletrônico e o cartão. É
preciso determinar que tipo de objetos são esses. Uma outra dúvida é a respeito do cartão ser
objeto ou agente.

Obviamente, como esse exemplo é bastante simples e a aplicação também é muito conhecida,
parece desnecessário obter mais conhecimentos a respeito. Entretanto, como o objetivo aqui é
exemplificar a técnica, mostraremos como pode-se questionar a respeito dessa aplicação.
O analista deve então realizar uma série de questões sobre as proposições. Nesse
questionamento o analista precisa determinar qual o relacionamento entre a resposta e a
proposição que originou a pergunta.

As questões da categoria por que, visam responder "razões" (metas) e "causas" a respeito de
eventos da narrativa. As questões da categoria como oferecem maiores detalhes a respeito de
determinados eventos, permitindo determinar sub-tarefas e maiores detalhes sobre a interação.
Questões da categoria o que podem ser feitas sobre objetos, e revelam atributos e hieraquias de
objetos. Perguntas de verificação podem ser feitas para se saber se as proposições estão sendo
entendidas corretamente. As perguntas de verificação são as que têm resposta sim/não. Uma
taxonomia mais completa ainda está sendo pesquisada pelos autores do método.

Continuando o exemplo anterior a tabela abaixo descreve uma seção de questionamento

sistemático:

Questões "por que"

Por que o cartão entra no caixa eletrônico?

_ Para iniciar. (evento conseqüente)
_ E então a máquina saberá quem é o cliente. (estado conseqüente)
Por que o cliente digita sua senha?
_ Para provar que ele é o usuário autorizado. (meta)
Por que o cliente pressiona o botão de saque rápido?
_ Porque é o botão para saques de R$ 100,00 (critério de descriminação).
_ Para evitar a digitação (cenário alternativo).
_ Porque ele está com pressa (causa)

Questões "como"

Como o cliente põe o cartão?

_ O cliente tira o cartão de sua bolsa e
_ insere no local apropriado no caixa eletrônico..
Como o cliente digita a senha?
_ Pressionando os botões adequados.
Como o cliente pressiona o botão de saque rápido?
_ Colocando o seu dedo nele.

Questões "o que"

 O que é um botão de saque rápido?
_ É um tipo de botão que se pode pressionar.
O que é um botão?
_ É um dispositivo de controle no painel do caixa eletrônico.

Observe que se o analista estivesse utilizando essa técnica para num método orientado a
objetos, outras questões poderiam ser realizadas com outros objetivos de acordo com as
necessidades do método, como, por exemplo, para determinar classes e hierarquia de classes.

Após os cenários estarem desenvolvidos, os analistas devem trabalhar em conjunto com os

usuários para avaliá-los e refiná-los. Isto pode ser feito, por exemplo, colocando-
se posters numa sala pela qual os usuários podem circular livremente e observar os diversos
cenários. Cada cenário deve apresentar quadros (desenhos, gráficos, fotografias, etc.),
usando storyboards por exemplo, e uma descrição narrativa da tarefa. Os usuários, munidos de
papeis e lápis, podem fazer anotações (críticas e sugestões) e anexá-las a cada poster.

Considerações finais sobre cenários

O resultado da modelagem através de cenários é uma base para a compreensão de quem são
os usuários, quais a tarefas envolvidas e quais funções a interface e a aplicação devem prover,
de maneira que, já se possa ter meios de garantir a usabilidade do sistema.

A idéia de cenários em análise não está necessariamente associada à técnica de questionamento

sistemático. Os cenários são extremamente úteis para descrição do domínio. A técnica
sistematiza o processo de compreensão do conhecimento adquirido.

Os métodos em geral, e esse não deve fugir à regra, devem ser usados, não como uma camisa-
de-força que limite o processo de análise, mas como ferramentas que orientam os analistas e
aumentam sua capacidade intelectual.

4.4 Análise de Usuários

Para que o sistema seja construído como uma ferramenta de apoio às atividades de usuários
no domínio de aplicação, é preciso conhecer quem são os usuários e quais as suas
necessidades, isto é quais tarefas eles necessitam realizar. A análise de usuários deve
determinar quem eles são e quais tarefas eles normalmente fazem no domínio. Ela envolve a
descrição dos diferentes papéis de usuários e qual o conhecimento, capacidade e cultura
possuem os futuros usuários do sistema.
4.4.1 Análise de Perfis de Usuários
A análise do perfil dos diversos usuários do sistema descreve as várias características que
podem influenciar as decisões dos projetistas no desenvolvimento do sistema. Os objetivos são
assegurar que certas propriedades do sistema estejam adequadas ao conhecimento, cultura e
capacidades do usuário, e que potenciais deficiências sejam levadas em consideração. Por
exemplo, para um software de acompanhamento de pacientes em hospital, certos termos
específicos da medicina devem ser incluídos nas telas do sistema e devem ser evitados termos
técnicos de informática ( forneça informações patológicas ao invés de entrar dados da
doença). Para usuários com alguma deficiência física ou motora, elemento da interface devem
ser modificados, como por exemplo, tela de maior tamanho e letras maiores para deficientes
visuais.

Os perfil do usuário pode ser analisado através de formulários do tipo:

Perfil do Usuário

Nome do Sistema:
____________________________________________________________________
Função do Usuário:
___________________________________________________________________

Conhecimento e Experiência do Usuário

Nível educacional Língua Nativa Nível de leitura e expressão

( ) Ensino fundamental ( ) Português ( ) Excelente
( ) Ensino médio ( ) Inglês ( ) Bom
( ) Graduação ( ) outra: ___________________ ( ) Regular
( ) Pós-Graduação ( ) Ruim

Experiência com computadores Experiência com sistema similar Conhecimento sobre o domínio
( ) Iniciante ( ) Utiliza bastante um similar ( ) Elementar
( ) Intermediário ( ) Já utilizou um similar ( ) Intermediário
( ) Experiente ( ) Nunca utilizou um similar ( ) Especialista no domínio

Características Físicas

Manipulação Deficiências
( ) Canhoto ( ) Auditiva
( ) Destro ( ) Visual
( ) Ambidestro ( ) Corporal
( ) Vocal

O perfil deve dar as informações necessárias que os desenvolvedores precisam para tomar as
suas decisões. A análise do perfil pode ser adaptada de acordo com as características do sistema
e com as necessidades de analistas e desenvolvedores. Por exemplo, pode ser interesse dos
designers saber se os usuários têm algumas experiência com interfaces gráficas e qual o padrão
(Windows, Motif, Macintosh, etc.) eles estão acostumados a utilizar.

4.4.2 Papéis de Usuários

O papel (ou função ) específico de cada usuário é definido pelas tarefas que eles realizam.
Numa organização, as pessoas trabalham juntas, de maneira estruturada. A estrutura da
organização define relacionamentos entre as pessoas. A implicação imediata dos diferentes
papéis de cada usuário são as diferentes tarefas que eles irão realizar. Algumas tarefas podem
ser comuns a diferentes papéis de usuários, enquanto outras podem ser exclusivas de papéis
específicos.

O conceito de papel de usuário permite abstrairmos as características específicas de um usuário

e enfatizar nas diferentes necessidades associadas a função que ele exerce. Para cada papel
devemos associar um conjunto de funções, como veremos mais adiante.

No domínio do departamento de informática da UFRN podemos identificar como papéis de

usuários: secretário do departamento, chefe, coordenador de graduação, secretário da
coordenação, coordenador de pós-graduação, professor, aluno, funcionário de administração
de laboratórios e usuário externo.

4.5 Análise e Modelagem de Tarefas

Os cenários permitem o levantamento e a descrição mais global das informações, das tarefas e
dos problemas do domínio. O perfil de usuário descreve as características de usuários em
termo de conhecimento, cultura, capacidades e limitações. A análise de tarefas visa determinar
quais as atividades que os usuários (ou cada papel de usuário) devem realizar. Esta informação
é essencial para se especificar os requisitos funcionais, determinando a funcionalidade do
software. Para que o sistema possa ser construído para que estes problemas sejam resolvidos,
ele deve ser uma ferramenta auxiliar na realização das tarefas de cada usuário.

Uma tarefa é, genericamente, uma atividade na qual um ou mais agentes tentam atingir uma
meta especificada, através de uma mudança de estado em uma ou mais entidades do mundo.
Num domínio de aplicação, as tarefas são as atividades que modificam estados de elementos
deste domínio. A construção de um sistema computacional em um certo domínio tem por
objetivo apoiar a realização de algumas destas atividades. Durante o processo de análise, deve-
se determinar quais as do domínio e identificar quais delas podem ser auxiliadas pelo sistema.

A análise e modelagem de tarefas visa descrever as principais as tarefas que cada usuário do
sistema terá de realizar para que os projetistas possam elaborar quais funções o sistema deve
oferecer para que elas possam ser desempenhadas. Estas tarefas são descritas em termos de
metas e um planejamento de possíveis atividades necessárias para atingi-las. As tarefas podem
ser descritas a partir das informações obtidas nos cenários e devem ser agrupadas por papéis de
usuário.

A análise de tarefas pode ser utilizadas nas diversas fases do ciclo de vida do software. Na fase
de análise de requisitos ela pode ser utilizada para identificar problemas na maneira de como as
tarefas vêm sendo realizadas. Os modelos de tarefas também podem descrever quais tarefas
podem ser realizadas com o auxílio do sistema e como os usuários gostariam que ela fosse
realizada. A análise de tarefa também é utilizada na avaliação do sistema para se determinar se
como os usuários estão utilizando o sistema e se os objetivos foram atingidos. Nestes casos, a
análise de tarefas ajuda ao projetista da interface ter uma visão da aplicação sob a perspectiva do
usuário, isto é, um modelo das tarefas do usuário quando executando sessões da aplicação.
4.5.1 Modelo de tarefas como base para a especificação de requisitos funcionais
A análise e modelagem de tarefas pode ser utilizada como base para a especificação de
requisitos funcionais. Para isto é preciso descrever as metas associadas a cada papel de
usuário, que permitirão saber o que os usuário querem.

Resultados da psicologia cognitiva mostram que as pessoas realizam tarefas

estabelecendo metas e elaborando um plano para cada uma delas. O planejamentoconsiste
numa decomposição hierárquica de metas em sub-metas até que elas possam ser atingidas
por operações. O plano ou método é, portanto, uma estrutura de sub-metas e operações para se
atingir um certa meta. As operações correspondem a ações básicas humanas, isto é, aquelas que
qualquer pessoa pode e sabe como realizar. São exemplos de operações escrever uma palavra
ou frase, ler uma informação, falar uma palavra ou frase, andar, relembrar, mover um objeto,
pressionar um botão de controle e várias outras.

Por exemplo, suponhamos que uma pessoa tem como meta avisar a um amigo, através de uma
carta, que sua filha nasceu. Para atingir seu objetivo a pessoa deve estabelecer duas sub-metas:
Escrever a carta e Colocá-la no correio. A sub-meta escrever carta pode ser atingida pelo
método: Conseguir papel e lápis eEscrever mensagem. Escrever mensagem já pode ser
considerada uma operação, enquanto que conseguir papel e lápis requer um novo planejamento
que determine as seguintes operações: ir até o escritório, abrir o armário, pegar o papel e o
lápis, levá-los até a mesa.
O grão de refinamento do que podemos considerar com sendo uma operação é bastante
subjetivo. Vai depender das dificuldades de quem realiza o plano. Na prática o plano é
necessário quando a pessoa que vai realizar as ações não sabe ainda qual o método. Com a
experiência o método torna-se automático e podemos considerar uma sub-meta como uma
operação

Na utilização de um sistema computacional, os usuários realizam tarefas com o objetivo de

atingir certas metas. Uma meta é um determinado estado do sistema ou de objetos do sistema ao
qual o usuário quer chegar. Ao estabelecer a meta o usuário deve realizar um planejamento
decompondo a meta em sub-metas até que ele saiba que existe uma determinada função do
sistema que permita que sua meta seja atingida. O caso agora é um pouco diferente do
planejamento anterior, pois não é o usuário quem vai realizar a operação desejada, mas o
sistema. A decomposição deve ocorrer até que ele identifique que o sistema tem uma
determinada função que quando executada realiza a operação necessária para que sua meta seja
atingida. Chamamos estas operações que o sistema executa para satisfazer as metas do usuário
de função da aplicação. O conjunto de funções da aplicação determina a funcionalidade do
sistema.

Vejamos um exemplo. Suponha que o usuário esteja escrevendo uma carta utilizando um editor
de texto e tenha como meta formatar um documento.Para atingir esta meta ele estabelece as
seguintes sub-metas: Formatar página, Formatar parágrafos, Formatar fontes. Para cada uma
destas sub-metas ele estabelece novas sub-metas até que ele identifique no software funções que
o sistema pode realizar que permitam que as sub-metas sejam atingidas. Por exemplo, formatar
página pode ser decomposta na função da aplicação especificar tamanho da página e na sub-
meta definir margens. Esta última por sua vez pode ser atingida pelas operações especificar
valor da margem superior, especificar valor da margem inferior, especificar valor da margem
esquerda e especificar valor da margem direita.
Vejamos o plano deste usuário

META: Formatar documento

PLANO:

Formatar página (sub-meta)

especificar tamanho da página (função da aplicação )

Definir margens (sub-meta)

especificar valor da margem superior (função da aplicação)

especificar valor da margem inferior (função da aplicação)
especificar valor da margem esquerda (função da aplicação)
especificar valor da margem direita (função da aplicação)

Formatar parágrafos (sub-meta)

selecionar parágrado (função da aplicação)

Especificar atributos do parágrafo (sub-meta)

especificar espaçamento (função da aplicação)

especificar recuos (função da aplicação)

...

Formatar fontes (sub-meta)

...

O modelo de tarefas é extremamente útil para determinarmos as metas dos usuários e quais
funções da aplicação eles gostariam que o sistema oferecesse. Por exemplo, a especificação
dos requisitos pode determinar que deve existir uma função da aplicação para formatar
documento de maneira que a meta do usuário pudesse ser atingida pelo sistema sem a
necessidade de planejamento algum.

É importante ressaltar que uma meta pode ser satisfeita por uma única ou por várias funções da
aplicação e que também mais de um método pode ser atingido uma mesma função da
aplicação.Por exemplo, ao utilizar o Word 7.0, o usuário pode ter como meta formatar um estilo.
Ao construir o seu plano o usuário em determinado momento pode estabelecer a sub-meta
Especificar atributos do parágrafo. Esta sub-meta requer as mesmas funções de aplicação do
plano para a meta formatar parágrafo. Assim, temos um grupo de funções da aplicação que são
utilizadas para duas (ou mais) metas distintas.

Para que o usuário solicite ao sistema que execute uma determinada função de usuário, ele deve
realizar operações que correspondam a um comando de função. Por exemplo, para o usuário
solicitar ao sistema operacional que realize a função de copiar um arquivo de um diretório para
outro ele deve escrever um comando do tipo copy nome1 dir1 dir2 ou se estiver numa interface
gráfica, mover o ícone correspondente ao arquivo da janela do diretório para a do outro
diretório. Ao realizar o comando, o usuário precisa realizar operações com os dispositivos de
interface do sistema, como pressionar mouse, digitar número, teclar enter, etc.

Apenas com a descrição das operações do usuário é que um plano para atingir uma meta fica
completo. Quando o sistema está pronto, o plano tem que determinar exatamente as operações
necessárias para comandar a função e, conseqüentemente, ter a meta atingida com o auxílio do
sistema.

Na especificação de requisitos é suficiente decompor as metas que o usuário quer atingir nas
correspondentes sub-metas. Caberá ao designer do software determinar qual o conjunto de
funções que permita atingir o maior número possível de metas para cada papel de usuário e
quais devem ser os comandos de interface para cada uma das funções.

4.5.2 Modelagem de Tarefas usando GOMS

Neste curso, utilizaremos a análise de tarefas na especificação de requisitos para determinar as
tarefas que os usuários necessitam realizar com o sistema a ser construído. Para isto
utilizaremos um método específico que utiliza o modelo GOMS simplificado. O
modelo GOMS (Goals, Operators, Methods, and Selection Rules) oferece uma abodagem de
análise da tarefa baseada num modelo do comportamento humano que possui três
subsistemas de interação: o perceptual(auditivo e visual), o motor (movimentos braço-mão-
dedo e cabeça-olho), e cognitivo (tomadas de decisão e acesso a memória). O modelos GOMS
descreve o comportamento dinâmico da interação com um computador, especificando-se:

Metas - Uma aplicação é desenvolvida para auxiliar os usuários atingirem metas

específicas. Isso requer uma série de etapas. Dessa forma, uma meta pode ser
decomposta em várias submetas, formando uma hierarquia.

Operadores - São as ações humanas básicas que os usuários executam.

perceptual - operações visuais e auditivas (olhar a tela, escutar um beep).

motor - movimentos braço-mão-dedo e cabeça-olho (pressionar uma tecla).

cognitivo - tomadas de decisão, armazenar e relembrar um item da memória de

trabalho.

Métodos - Um método é uma sequência de passos para se atingir uma meta.

Dependendo do nível da hierarquia, os passos num método podem ser submetas,
operadores ou a combinação de ambos.

Regras de Seleção - Pode existir mais de um método para se atingir uma meta. Uma
regra de seleção especifica certas condições que devem ser satisfeitas antes que um
método possa ser aplicado. Uma regra de seleção é uma expressão do tipo "condição-
ação".
O GOMS permite que se construa modelos de tarefas bem mais complexos e detalhados do
que o necessário numa tarefa de análise para a especificação de requisitos. Usaremos uma
versão simplificada do GOMS, pois:

o modelo da tarefa não deverá descrever informações de design da interface,

uma vez que ela ainda não foi construída;
o analista não é um especialista em psicologia cognitiva;
o modelo simplificado pode ser expandido para o original, o que é bastante útil.

1. Diretrizes do Modelo de Tarefas Simplificado

Uma vez que a hierarquia de metas representa um aumento no nível de detalhe, se nos
limitarmos à descrição de metas e submetas de mais alto nível, nenhuma decisão de design
será envolvida.

Faça a análise "top-down" - comece das metas mais gerais em direção as mais
específicas.
Use termos gerais para descrever metas - não use termos específicos da
interface.
Examine todas as metas antes de descer para um nível mais baixo - isso facilita
reuso de metas.
Considere todas as alternativas de tarefas - as regras de seleção possibilitam
representar alternativas.
Use sentenças simples para especificar as metas - estruturas complexas indicam
a necessidade de decomposição da meta em submetas.
Retire os passos de um método que sejam operadores - os operadores são
dependentes da interface.
Pare a decomposição quando as descrições estiverem muito detalhadas -
quando os métodos são operadores ou envolvem pressuposições de design.

1. Modelagem da Tarefa para aplicações com múltiplas funções de usuários.

Se, para uma determinada aplicação, a função do usuário for um fator crítico dominante
na análise de usuários, deveremos ter modelos de tarefas diferentes para cada função de
usuário. No GOMS simplificado, veremos como representar as tarefas para cada usuário
num só modelo. Antes de estudarmos a notação do modelo, vejamos algumas regras para
modelos com múltiplas funções de usuários:

o Inicie especificando metas de alto nível para cada função de usuário.

o Se mais de um compartilham a mesma meta, agrupe-os sob uma só.
o Se todos compartilham a mesma meta, retire as referências a funções de usuário.
2. Notação
1. Notação para Funções de Usuários.

Funções de usuários distintas serão denotadas pelo símbolo FU seguido por um

número.

ex.: Gerente de vendas (FU1), balconista (FU2), caixa (FU3)

A descrição de cada função de usuário é a primeira parte do modelo de tarefas.

ex.: Gerente de vendas (FU1): responsável pela vendas nas lojas. Tem
acesso a todos os dados do sistema.

Um ponto-e-vírgula (;) é usado para separar o símbolo da função do usuário do

restante da notação do modelo de tarefas.

ex.: FU1;...

Se uma meta é usada para mais de uma função de usuário, elas devem ser
separadas por uma vírgula (,).

ex.: FU1, FU2; ...

Um asterisco (*) é usado se uma meta é aplicada a todas as funções de usuários.

ex.: *;...

1. Notação para especificação de metas

Cada passo num método é numerado numa ordem seqüencial, com cada nível de
decomposição separado por um ponto (.), e com a endentação apropriada para
reforçar a noção de hierarquia. Após o último número usa-se dois-pontos (:).

ex.: FU2; 2.1: Anotar correções.

Um comentário começa com duas barras inclinadas para direita (//) e acaba ao
final da linha.

ex.: // Para fazer as anotações o balconista deverá examinar as

// listagens produzida durante as vendas do dia.

FU2; 2.1: Anotar correções

Notação para Métodos e Regras de Seleção

 Se uma meta possui mais de um método para ser atingida, uma letra do alfabeto
é usada de forma ordenada após o número que descreve a meta.

ex.:

FU2; 2: Fazer relatório de vendas (meta)

FU2; 2A: ... (método A)

FU2; 2B: ... (método B)

As regras de seleção e o método associado são descritos como pares "condição-

ação", logo após a notação numérica da meta.

ex.: FU2; 2A: se (dia de hoje for sábado)

então (fazer relatório semanal)

1. Reutilizando Metas

Um aspecto importante dessa notação é que pode-se reutilizar metas, simplesmente

usando o mesmo número de uma meta preexistente.

ex.:

FU2; 2.1: Anotar correções. (meta preexistente)

...

FU1, FU3; 3: Modificar livro-caixa.

FU1, FU3; 3.1: Procurar lotes em aberto.

FU1, FU3; 2.1: Anotar correções. (meta reusada)

FU1, FU3; 3.3: Recalcular valores.

2. Diretrizes adicionais

Delimite os passos de um método entre chaves: {}.

Em aplicações com apenas uma função de usuário, não é necessário incluir a
notação de função usuário antes de cada meta.
Num nível de decomposição onde todas as metas têm o mesmo número-prefixo,
apenas o número que indica a seqüência naquele nível é necessário.
A diretriz anterior se aplica também à notação de função de usuário.
Ao reutilizar uma meta anterior é necessário usar a notação completa para ela.
 ex.: FU1, FU3; 3: Modificar livro-caixa.
1: Procurar lotes em aberto.

2.1: Anotar correções. (meta reusada)

3: Recalcular valores.

Principais Técnicas de Levantamento de Requisitos de Sistemas

leave a comment »

Engenharia de Requisitos – Técnicas

Créditos: Bruno Conde Perez Brum e Leandro Pena
Devido a falta de informação a respeito na internet e com muita documentação de
qualidade somente em inglês, resolvi postar este trabalho em meu blog como forma de
ajudar a todos que estão estudando esta área.

Por favor comentem se isto lhe ajudou de alguma forma ok?

1. Métodos de Conversação:
O método de conversação fornece um meio de comunicação verbal entre duas ou mais pessoas. Sendo
uma forma natural de expressar as necessidades, idéias e responder às perguntas, é bastante eficaz para
identificar e compreender as necessidades do entrevistado. Proporciona a comunicação verbal entre um ou
mais participantes e ajuda a comunicação eficaz com os mesmos. Esses métodos fornecem a maneira
natural de expressar as necessidades e as idéias e identificar os requisitos do produto.
1.1 Entrevistas (Interviews): A entrevista é uma das técnicas tradicionais mais simples de utilizar e que
produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê espaço ao
entrevistado para esclarecer as suas necessidades. É uma discussão do projeto desejado com diferentes
grupos de pessoas.
Principais Vantagens Principais Desvantagens
1) Com um plano geral bem elaborado, o analista terá 1) Podem ocorrer desvios de curso, no decorrer da
facilidade em descobrir que informação o usuário está entrevista;
mais interessado e usar um estilo adequado ao 2) Consumir mais tempo e recursos com sua realização;
entrevistar; 3) Tratamento diferenciado para os entrevistados;
2) Poder alterar o curso da entrevista de forma a obter 4) É necessário ter um plano de entrevista para que não
informações sobre aspectos importantes que não tinham haja dispersão do assunto principal e a entrevista fique
sido previstos no planejamento da entrevista; longa, deixando o entrevistado cansado e não produzindo
3) Poder alterar a ordem seqüencial das perguntas; bons resultados;
4) Poder eliminar perguntas anteriormente planejadas; 5) O usuário tem dificuldade de concentração em
5) Poder incluir perguntas que não estavam na reuniões muito longas;
programação da entrevista;6) Poder motivar o 6) O entrevistado pode não saber expressar corretamente
entrevistado no decorrer do processo; suas necessidades ao analista.
1.2 WorkShop: Trata-se de uma técnica de elicitação em grupo usada em uma reunião estruturada. Devem
fazer parte do grupo uma equipe de analistas e uma seleção dos stakeholders que melhor representam a
organização e o contexto em que o sistema será usado, obtendo assim um conjunto de requisitos bem
definidos.
Principais Vantagens Principais Desvantagens
1) Obtêm um conjunto de requisitos bem definido; 1) Por ser realizado por convocação por dia e horário,
2) Trabalho em equipe tornando o levantamento de pode ocasionar problemas no presenciais dos
requisitos mais eficaz; stakeholders;
3) Baixo custo e resposta relativamente rápida; 2) Não abre caminho para ideias externas além da equipe
4) Tempo de obtenção de informações é reduzido. de analistas; Dados excessivamente agregados.

1.3 BrainStorming: É utilizado normalmente em workshops. Após os workshops serão produzidas

documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser desenvolvido. Seu
objetivo é uma apresentação do problema/necessidade a um grupo específico, requerendo assim soluções.
Principais Vantagens Principais Desvantagens
1) Várias pessoas pensam melhor do que uma (grupo 1) Disponibilidade de todos pode inviabilizar o
pensante); levantamento de dados.
2) Rompe a inibição de idéias;
3) Generaliza a participação do membros do grupo.

1.4 Questionário: Diferente da entrevista, essa técnica é interessante quando temos uma quantidade
grande de pessoas para extrair as mesma informações. As questões são dirigidas por escrito aos
participantes com o objetivo de ter conhecimento sobre opiniões das mesmas questões. São auto-
aplicáveis pois o próprio informante responde.
Principais Vantagens Principais Desvantagens
1)Atinge um grande número de pessoas; Menores custos; 1) Não há garantia de que a maioria dos participantes
2) Permite que os participantes respondam no momento respondam o questionário;
em que acharem conveniente;3) Questões padronizadas 2) Os resultados são bastante críticos em relação ao
garantem uniformidade. objetivo, pois as perguntas podem ter significados
diferentes a cada participante questionado.

1.5 Grupo Focal (Focus Group): É um grupo de discussão informal e de tamanho reduzido (até 12 pessoas),
com o propósito de obter informação qualitativa em profundidade. As pessoas são convidadas para
participar da discussão sobre determinado assunto.
Principais Vantagens Principais Desvantagens
1) Baixo custo, resposta rápida e Flexibilidade; 1) Exige facilitador/moderador com experiência para
2) Obtêm informações qualitativas a curto prazo;3) conduzir o grupo; Não garante total anonimato;
Eficiente para esclarecer questões complexas no 2) Depende da seleção criteriosa dos participantes;3)
desenvolvimento de projetos; Informações obtidas não podem ser generalizadas.

2. Métodos de Observação:
Utilizado para a compreensão do domínio da aplicação, observando as atividades humanas.
2.1 Etnografia (Ethnographic Study): É uma análise de componente social das tarefas desempenhadas numa
dada organização. É utilizado para desenvolver um entendimento completo e detalhado.
Principais Vantagens Principais Desvantagens
1) Capacidade de observar o comportamento do 1) Dificuldades para analisar e interpretar situações;
ambiente, gerando maior profundidade no conhecimento. 2) A amostra pode ser reduzida;
2) Apoia-se no comportamento real; 3) Requer treinamento especializado;
3) Permite uma abordagem integral. 4) As observações podem ter uma interpretação
complicada.

2.2 Observação (Observation): A técnica resume-se em visitar o local em foco com a finalidade de
observação do mesmo. Permitindo assim, coletar informações de acordo com o cotidiano das operações e
execução dos processos diários do local.
Principais Vantagens Principais Desvantagens
1) Capaz de captar o comportamento natural das 1) Polarizada pelo observador;
pessoas; 2) Requer treinamento especializado;
2) Nível de intromissão relativamente baixo; 3) Efeitos do observador nas pessoas;
3) Confiável para observações com baixo nível de 4) Não comprova/esclarece o observado;5) Número
inferência. restrito de variáveis.

2.3 Protocolo de Análise (Protocol Analysis): Análise de protocolo é uma forma de levantamento de
requisitos no qual o analista analisa as partes interessadas quando estão envolvidas em algum tipo de
tarefas.
Principais Vantagens Principais Desvantagens
1) Processo de extração de registro de tarefas via audio, 1) o analista deve ter conhecimento suficiente sobre
vídeo ou notas escritas. domínio atual, a fim de compreender melhor as tarefas.

3. Métodos Analíticos:
Conjunto de técnicas para analise de documentação e conhecimento existentes com o intuito de adquirir
requisitos através do levantamento de informação pertinentes ao sistema a ser especificado, como por
exemplo, domínio do negócio, fluxos de trabalho e características do produto.

Principais Vantagens Principais Desvantagens

1) O estudo do conhecimento de especialistas leva a um
processo sucessivo de aumento de maturidade e
qualidade;
2) Reutilização de informação já disponível salva tempo e
custo;
1) Requer dados empíricos, documentação e a opinião de
expecialistas, e sem estes, não é possível identificar os
requisitos;
2) Podem levar a restrição da visão do produto final;
3) Lida com informação antiga, e com isso pode levar a
replicação de erros existentes;

3.1 Reuso de Requisitos: Estudo e reutilização de especificações e glossários referente a projetos de

sistemas legados ou sistemas de mesma família (com funcionalidades de negócio similares).
Principais Vantagens
1) Economia de tempo e dinheiro: Estudos tem mostrado que sistemas similares podem reutilizar acima de 80% de
seus requisitos; Pode levar a uma reutilização adicional de outros itens em outras atividades do ciclo de vida de
desenvolvimento (ex.: reuso do design de componentes já existentes, testes e código fonte);2) Redução de risco:
Requerimentos reutilizados tem uma chance maior de serem compreendidos pelos stakeholders visto que já são
conhecidos de certa forma;

3.2 Estudo de Documentação / Analise de Conteúdo: Estudo e reutilização de documentação de diferentes

naturezas, para a identificação de requisitos a serem implementados no sistema que se
estámodelando.Uma grande variedade de documentação pode ser analisada incluindo estrutura
organizacional da empresa, padrões de mercado, leis, manuais de usuário, relatório de pesquisas de
mercado, glossário de termos de negócio, etc.
Principais Desvantagens: Documentos com problemas podem levar a uma falha na definição dos requisitos;

3.3 Laddering: É um método de entrevistas estruturadas, um-a-um, utilizado para o levantamento de

conhecimento (o que é importante e por que) de especialistas, e que consiste na criação, revisão e
modificação da hierarquia de conhecimento dos especialistas geralmente na forma de diagramas
hierárquicos (ex.: diagrama em árvore).
Principais Vantagens Principais Desvantagens
1) Cobre um amplo domínio de requisitos; 1) Não é capaz de extrair todos os tipos de requisitos;
2) Necessita de menos tempo para a preparação e 2) Necessita da execução combinada de outras técnicas
execução das sessões de levantamento; de levantamento de requisitos para sua complementação
3) Necessita de menos experiência para a execução das em determinados domínios;
sessões de levantamento; 3) Não é compatível com todo e qualquer domínio
4) Provê um formato padrão que é adaptável para a de requisitos, sendo necessário a verificação de sua
automação computadorizada; adequação ao levantamento a ser feito;

3.4 Sorteio de Cartões: Utilizado para capturar informações e idéias sobre estrutura de requisitos de
especialistas de domínio. Neste método um conjunto de cartões é distribuído em um grupo de
stakeholders onde cada cartão é impresso com a descrição das entidades do domínio.
Principais Vantagens
1) Ajuda os stakeholders a levantar os conceitos do domínio e distinguir entre problemas de alto e baixo nível;
2) O resultado do método pode ser utilizado como insumo para outros métodos de levantamento de requisitos;

3.5 Repertory Grid: Método onde os stakeholders são questionados sobre atributos e valores destes,
referentes a uma série de entidades. Com esta informação é montada uma matrix de entidade X atributo.

4. Métodos Sintéticos:
Algumas vezes em projetos complexos um único método de levantamento de requisitos não é suficiente
para capturar os requisitos detalhadamente. Para solucionar este problema os analistas de requisitos
tentam utilizar diferentes métodos de levantamento de requisitos. Por exemplo, em alguns casos é
utilizado o método de entrevista antes de se fazer um estudo etinográfico. Ao invés de utilizar a
combinação de diferentes técnicas de levantamento de requisitos, é possível utilizar métodos sintéticos,
que são formados pela combinação das outras técnicas em uma única.

4.1 Sessões JAD/RAD: Consiste em workshops e sessões de grupo nos quais stakeholders e analistas de
requisitos se encontram para discutir as características desejadas do produto. Seu objetivo é envolver
todos os stakeholders importantes no processo de levantamento, através de reuniões estruturadas e com
foco bem definido. Depende diretamente do grau de envolvimento dos stakeholders bem como do líder
das sessões JAD.
O processo JAD consiste em três fases principais: customização, sessões e agrupamento. Na
customização, o analista prepara as tarefas para as sessões como organizar os times, preparar o material,
etc. Na fase de sessões, o analista marca uma ou mais reuniões com os stakeholders. No inicio da sessão
JAD o engenheiro de requisitos provê uma visão genérica sobre o sistema e a discussão com os
stakeholders continua até o fim do levantamento de requisitos. Na fase de agrupamento todos os
requisitos levantados nas fases anteriores são convertidos em documentos de especificação de requisitos.

Principais Vantagens Principais Desvantagens

1) As discussões que ocorrem na fase de sessões são
altamente produtivas porque resolvem dificuldades entre
as partes enquanto se dá o desenvolvimento do sistema
para a empresa;
2) Melhor aplicado para grandes e complexos projetos;
1) Somente projetos que possuem pelo menos uma das
características abaixo podem utilizar o JAD:- Possuir alto
número de stakeholders responsáveis por departamentos
cross na empresa;- Primeiro projeto na empresa o qual é
considerado crítico para o futuro da mesma;
2) Requer mais recursos se comparado à métodos
tradicionais;

4.2 Prototipação: Utilizado no estágio inicial do projeto. Ajuda aos stakeholders a desenvolver uma forte
noção sobre a aplicação a qual ainda não foi implementada, que através da visualização da mesma eles
podem identificar os reais requisitos e fluxos de trabalho do sistema. É muito utilizado quando os
stakeholders são incapazes de expressar os seus requisitos ou se os mesmos não têm nenhuma
experiência com o sistema.
Principais Vantagens Principais Desvantagens
1) Permite alcançar um feedback antecipado dos 1) Demanda um alto custo de investimento, em relação à
stakeholders; outros métodos, para ser realizado;
2) Reduão de tempo e custo de desenvolvimento devido a 2) Demanda um tempo maior para sua realização devido
detecção dos erros em uma fase inicial do projeto; a complexidade do sistema e a limitações técnicas;
3) Prove alto nível de satisfação dos usuários devido a
sensação de segurança ao ver algo próximo do real;

4.3 Questionário de Ambiente: Permite aos analistas o real entendimento das necessidades dos
stakeholders com a coleta detalhada de informações através de observação e interação com as pessoas no
ambiente de trabalho. Alguns profissionais são escolhidos e acompanhados a fundo para o completo
entendimento de suas práticas de trabalho.
Principais Vantagens Principais Desvantagens
1) Permite um levantamento profundo e detalhado das 1) Dependendo dos processos de trabalho, necessita de
necessidades dos stakeholders; uma grande quantidade de tempo e pessoas para ser
2) Pode ser utilizado para resolver problemas executado;
extremamente complexos;

4.4 Storyboards: São sessões interativas que descreve uma sequência de atividades e eventos para um caso
em específico para um processo genérico que é esperado que o sistema automatize.
Principais Vantagens
1) Método muito eficiente no esclarecimento de requisitos relacionados a processos, fluxos de dados e tarefas;
2) Método relativamente barato de ser executado;

Conclusão:
Todos os métodos de levantamento de requisitos possuem vantagens e desvantagens a serem
consideradas e nenhum deles é completo dadas as inúmeras variáveis de complexidade, perfil de
stakeholders, comunicação, nível de conhecimento do negócio, nível de qualificação dos profissionais de
levantamento de requisitos, situações políticas, nível de comprometimento dos stakeholders, etc. Com
isso, a utilização de mais de uma técnica, de forma combinada, ou a utilização de técnicas sintéticas, irá
ajudar na complementação de possíveis lacunas de levantamento, além de melhorar a qualidade e
completude dos requisitos visto que pode ocorrer o batimento cruzado de requisitos similares. Outro fator
importante é a utilização de um framework de decisão para a escolha dos métodos mais apropriados dado
o contexto do trabalho a ser realizado.

oas práticas para análise e levantamento de requisitos

Resolvi abordar o tema de levantamento de requisitos dentro
de gerenciamento de projetos, lembrando que minhas diretrizes
e apontadores são baseados nos estudos do PMBOK do PMI.
Muitos sentem uma tremenda dificuldade na hora de lidar com o
levantamento feito no inicio do projeto, principalmente aqueles
que já pegam um projeto iniciado e tem que absolver tudo e
buscar a melhor maneira de entender o que está acontecendo.
Em função disso estão os Focais para ajudar na Interpretação
do projeto.
Primeiramente gostaria de ressaltar que o modo de levantamento
varia da hierarquia que você trabalha.
Se faz necessário um documento padrão para coleta de dados
para que o gerente possa interpretar os dados necessários para
dar continuidade no cronograma.
Ao fazer a primeira abordagem ao cliente aonde vai ser
implantado o Sistema ou Ferramenta verifique se a viabilidade de
atender aos requisitos desse projeto, caso não tenha o know-
how, abra a pauta e coloque todas as dúvidas e alinhe com o
seu gerente, em caso de divergência o gerente se encarrega de
resolver esse problema com o cliente.
Durante a reunião com o cliente e as partes interessadas faça as
perguntas certas ao “analista operacional (cliente)” que estará
encarregado de mostrar como é o AS-IS da empresa.
Faça com que as respostas obtidas do cliente não deixem
nenhuma questão pendente de interpretação, isso pode
acarretar atraso no projeto, custo e ,muita dor de cabeça…
Baseado no que seu gerente requer de você, a precisão de
dados faz com que o projeto aconteça claramente e sem pausas
desnecesárias.
Uma pergunta mal feita ou mal interpretada pode acarretar em
um “ponto zero” ou famoso … Quem faz o quê aqui? e começa
o looping de reuniões de contratempo, Sempre esteja atento
ao ESCOPO.
Dentro dos processos, onde os analistas ficam quebrando a
cabeça procurando por informação que não foi repassada do
cliente para a consultoria quando na verdade a falha está na
comunicação interna, evidencie tudo o que fizer no projeto e
apresente a solução.
Este erro é muito comum em empresas que colocam analistas
que são bons em seguir processo porém não intendem uma
virgula do que realmente faz! são os famosos soldadinhos da
empresa com procedimentos em mãos para explicar ao analista
de requisitos como funciona o processo e não o sistema.
Abaixo cito Alguns apontadores que faço prática:
WorkShop: Trata-se de uma técnica de elicitação em grupo
usada em uma reunião estruturada. Devem fazer parte do grupo
uma equipe de analistas e uma seleção dos stakeholders que
melhor representam a organização e o contexto em que o
sistema será usado, obtendo assim um conjunto de requisitos
bem definidos.
(Entrevistas): A entrevista é uma das técnicas tradicionais mais
simples de utilizar e que produz bons resultados na fase inicial
de obtenção de dados. Convém que o entrevistador dê espaço
ao entrevistado para esclarecer as suas necessidades. É uma
discussão do projeto desejado com diferentes grupos de
pessoas.
BrainStorming: É utilizado normalmente em workshops. Após
os workshops serão produzidas documentações que refletem os
requisitos e decisões tomadas sobre o sistema a ser
desenvolvido. Seu objetivo é uma apresentação do
problema/necessidade a um grupo específico, requerendo assim
soluções.
Questionário: Diferente da entrevista, essa técnica é
interessante quando temos uma quantidade grande de pessoas
para extrair as mesma informações. As questões são dirigidas
por escrito aos participantes com o objetivo de ter conhecimento
sobre opiniões das mesmas questões. São auto-aplicáveis pois o
próprio informante responde.
Grupo Focal (Focus Group): É um grupo de discussão informal
e de tamanho reduzido (até 12 pessoas), com o propósito de
obter informação qualitativa em profundidade. As pessoas são
convidadas para participar da discussão sobre determinado
assunto.

O que é UML e Diagramas de Caso

de Uso: Introdução Prática à UML
Veja neste artigo um estudo prático sobre UML e uma introdução a um de
seus principais diagramas, o diagrama de Casos de Uso.

(45) (0)

Publicidade
Olá a todos.

Todos os meus artigos que publiquei na DevMedia até hoje foram artigos técnicos voltados para a linguagem C#.

Porém neste artigo, vamos sair um pouco dessa tônica e tentar explicar os fundamentos de uma linguagem muito

importante não só para desenvolvedores, mas para todos os profissionais que se envolvem em projetos de

desenvolvimento de sistemas e clientes.

Nesta série de artigos veremos o que é UML, para que serve e alguns exemplos práticos dos seus diagramas mais

comumente utilizados.

O que é UML?
UML é um acrônimo para a expressão Unified Modeling
Language. Pela definição de seu nome, vemos que UML é uma
linguagem que define uma série de artefatos que nos ajuda na
tarefa de modelar e documentar os sistemas orientados a
objetos que desenvolvemos.

Ela possui nove tipos de diagramas que são usados para

documentar e modelar diversos aspectos dos sistemas.

A maioria dos problemas encontrados em sistemas orientados a

objetos tem sua origem na construção do modelo, no desenho
do sistema. Muitas vezes as empresas e profissionais não dão
muita ênfase à essa fase do projeto, e acabam cometendo
diversos erros de análise e modelagem. Isso quando há
modelagem, pois nós profissionais da área sabemos que muitas
vezes o projeto começa já na fase de codificação.

Diagrama de Casos de Uso

Esse diagrama documenta o que o sistema faz do ponto de vista
do usuário. Em outras palavras, ele descreve as principais
funcionalidades do sistema e a interação dessas funcionalidades
com os usuários do mesmo sistema. Nesse diagrama não nos
aprofundamos em detalhes técnicos que dizem como o sistema
faz.

Este artefato é comumente derivado da especificação de

requisitos, que por sua vez não faz parte da UML. Pode ser
utilizado também para criar o documento de requisitos.

Diagramas de Casos de Uso são compostos basicamente por

quatro partes:

Cenário: Sequência de eventos que acontecem

quando um usuário interage com o sistema.
Ator: Usuário do sistema, ou melhor, um tipo de
usuário.
Use Case: É uma tarefa ou uma funcionalidade
realizada pelo ator (usuário)
Comunicação: è o que liga um ator com um caso
de uso
Vamos criar um cenário de exemplo para vermos a notação de
um diagrama de caso de uso:

“A clínica médica Saúde Perfeita precisa de um sistema de

agendamento de consultas e exames. Um paciente entra em
contato com a clínica para marcar consultas visando realizar um
check-up anual com seu médico de preferência. A recepcionista
procura data e hora disponível mais próxima na agenda do
médico e marca as consultas. Posteriormente o paciente realiza
a consulta, e nela o médico pode prescrever medicações e
exames, caso necessário”.

Com esse cenário simples podemos começar a criar nosso

diagrama. Inicialmente vamos definir nossos atores:

a) Paciente

b) Secretária

c) Médico

Agora vamos definir algumas ações de cada usuário:

a) Paciente

· Solicita Consulta

· Solicita Cancelamento de Consulta

b) Secretária

· Consulta Agenda

· Marca Consulta

· Cancela Consulta

c) Médico

· Realiza Consulta

· Prescreve Medicação
· Solicita Realização de exames

Bom, agora já temos uma relação de atores e ações

relacionadas a esses atores. Poderíamos criar um documento
textual (como foi feito acima), para registrar nossos atores e
funcionalidades. Mas o leitor não concorda que uma imagem
vale mais que mil palavras? Pois bem, podemos expressar tudo
o que definimos em um desenho simples utilizando os padrões
da UML para documentação de casos de uso.

No quadro abaixo segue a definição de algumas figuras do

diagrama:

No mercado existem diversos tipos de ferramentas case que

auxiliam na construção de diagramas. o leitor fique a vontade
de utilizar a ferramenta de sua preferencia. Algumas sugestões
seriam as versões trial do Enterprise Architect, ou do Visio.

Podemos agora construir o diagrama:

Como podemos observar esse diagrama composto por
desenhos simples descrevem de maneira bem objetiva o que
textualmente poderia ficar extenso. Nele vemos as
funcionalidades do sistema e as interações dos usuários com
elas.

Para melhorar um pouco mais esse diagrama vamos ver o

conceito de include>>. Include e extend são relações entre os
casos de uso.
 Include: seria a relação de um caso de uso que
para ter sua funcionalidade executada precisa
chamar outro caso de uso.
Extend: Esta relação significa que o caso de uso
extendido vai funcionar exatamente como o caso
de uso base só que alguns passos novos
inseridos no caso de uso extendido.
Tanto um como o outro, são notados como setas tracejadas
com o texto include>> ou extend>>.

Sabendo disso podemos modificar o diagrama inserindo um

novo caso de uso “Consultar Agenda”, que será utilizado no
caso de uso “Marca Consulta”. Pois a secretária, antes de
marcar precisa verificar a disponibilidade da agenda do médico
certo?
O leitor não concorda que esse tipo de diagrama é
extremamente simples e útil? Com ele podemos trabalhar em
três áreas muito importantes nos projetos:

1) Definição de Requisitos: Novos casos de usos geralmente

geram novos requisitos conforme o sistema vai sendo analisado
e modelado;
2) Comunicação com os Clientes: Pela sua simplicidade, sua
compreensão não exige conhecimentos técnicos, portanto o
cliente pode entender muito bem esse diagrama, que auxilia o
pessoal técnico na comunicação com clientes

3) Geração de Casos de Teste: A junção de todos os cenários

para um caso de uso pode sugerir uma bateria de testes para
cada cenário

Com isso chegamos ao fim desta parte do nosso artigo. Espero

que tenham gostado. Por favos peço que deixem seus
comentários para que possamos melhorar a qualidade de
nossos artigos.
Casos de Uso
Diagrama de Casos de Uso

Objetivo

O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação

entre os analistas e o cliente.
Um diagrama de Caso de Uso descreve um cenário que mostra as
funcionalidades do sistema do ponto de vista do usuário.
O cliente deve ver no diagrama de Casos de Uso as principais
funcionalidades de seu sistema.
Notação
O diagrama de Caso de Uso é representado por:
atores;
casos de uso;
relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
associações entre atores e casos de uso;
generalizações entre os atores;
generalizações, extends e includes entre os casos de uso.
casos de uso podem opcionalmente estar envolvidos por um retângulo
que representa os limites do sistema.
Em maiores detalhes:
Atores
Um ator é representado por um boneco e um
rótulo com o nome do ator. Um ator é um
usuário do sistema, que pode ser um usuário
humano ou um outro sistema computacional.
Caso de uso
Um caso de uso é representado por uma
elipse e um rótulo com o nome do caso de
uso. Um caso de usodefine uma grande
função do sistema. A implicação é que uma
função pode ser estruturada em outras
funções e, portanto, um caso de uso pode ser
estruturado.
Relacionamentos
o Ajudam a descrever casos de uso
o Entre um ator e um caso de uso
 Associação
Define uma
funcionalidade do sistema
do ponto de vista do
usuário.
o Entre atores
 Generalização
- Os casos de uso de B são
tambémcasos de uso de A
- A tem seus próprios casos de
uso

o Entre casos de uso

 Include

Um relacionamento include de um caso de uso A para

um caso de uso B indica que B é essencial para o
comportamento de A. Pode ser dito também que
B is_part_of A.

 Extend

Um relacionamento extend de um caso de uso B para

um caso de uso A indica que o caso de uso B pode ser
 acrescentado para descrever o comportamento de A (não
é essencial). A extensão é inserida em um ponto de
extensão do caso de uso A.

Ponto de extensão em um caso de uso é uma indicação

de que outros casos de uso poderão ser adicionados a
ele. Quando o caso de uso for invocado, ele verificará se
suas extensões devem ou não serem invocadas.

Você entendeu?! Provavelmente, não. É que extend é

unanimemente considerado um conceito obscuro.

Vamos a novas explicações.

Quando se especifica B extends A, a semântica é:

· Dois casos de uso são

definidos: A e A extended by B;

· B é uma variação de A. Contém eventos

adicionais, para certas condições;

· Tem que ser especificado onde B é inserido em

A.

 Generalização ou Especialização (é_um)

caso de uso B é_um caso de uso A (A é uma

generalização de B, ou B é uma especialização de A).

Um relacionamento entre um caso de uso genérico para

um mais específico, que herda todas as características de
seu pai.

· Sistema

Limites do sistema: representado por um retângulo envolvendo

oscasos de uso que compõem o sistema.
Nome do sistema: Localizado dentro do retângulo.

Exemplo 1
Exemplo 2
Exemplos de Casos de Uso

Este exemplos apresentam alguns casos de uso tirados do livro "

Applying Use Cases: A Pratical Guide", Geri Schneider & Jason Winters,
Addison-Wesley, 1998.

Os exemplos estão estruturados como um hipertexto. Para cada de uso

do sistema será necessário clicar para ver a sua descrição. As
descrições alternativas para o caso de uso serão mostradas, mostrando
como a descrição pode evoluir de casos de usos simples para casos de
usos estendidos. (O exemplo ainda não está completo).

Sistema de Vendas
1 Fazer Pedido - versão 1

Cenário informal

O caso de uso começa quando o cliente seleciona "fazer pedido". O

cliente fornece seu nome e endereço. Se o cliente fornece apenas o
CEP, o sistema coloca automaticamente o a cidade e o estado. O cliente
fornece os códigos do produto. O sistema devolve as descrições e o
preço de cada produto. O sistema calculará os valores totais para cada
produto fornecido. O cliente fornece as informações sobre cartão de
crédito. Em seguida, ele submete os dados ao sistema. O sistema
verifica as informações fornecidas, marca o pedido como "pendente" e
envia as informações de pagamento para o sistema de contabilidade e
pagamento. Quando o pagamento é confirmado, o pedido é marcado
como "confirmado" e o número de pedido (NP) é dado ao cliente.

2 Verificar Pedido - versão 1

Atores

Cliente, Funcionário

Fluxo de Eventos Primário (caminho básico):

1. O caso de uso começa quando o cliente seleciona "Meu pedido".

 2. Usa Procurar Pedido
3. O Sistema mostra os dados da situação do pedido e o caso de uso
termina..

Fluxo de Secundário (caminho alternativo):

Se no passo 2, o pedido não foi encontrado, o sistema informa que o

pedido não está cadastrado e solicita que o usuário verifique se os dados
do pedido estão corretos.

Pré-condição:

O usuário ter feito o pedido

Pós-condição:

A situação do pedido não ter sido alterada.

3 Cancelar Pedido - versão 1

Atores

Cliente, Funcionário

Fluxo de Eventos Primário (caminho básico):

1. O caso de uso começa quando o cliente seleciona "Cancelar

Pedido".
2. Usa Procurar Pedido
3. O Sistema mostra os dados da situação do pedido e o caso de uso
termina..

Fluxo de Secundário (caminho alternativo):

Se no passo 2, o pedido não foi encontrado, o sistema informa que o

pedido não está cadastrado e solicita que o usuário verifique se os dados
do pedido estão corretos.

Pré-condição:

O usuário ter feito o pedido

Pós-condição:

A situação do pedido é marcada como cancelada. O registro do pedido

permanece para o histórico de pedidos.

6. Fornecer Produto - Versão 1

Cenário informal

O caso de uso começa quando o fornecedor pega a lista de produtos

requisitados. Em seguida os Fornecedores devem preencher um
formulario para informar a quantidade que pode ser fornecida e o preço
unitário dos diversos produtos, incluindo informações próprias como
cpf/cgc e nome. Após realizar a tomada de preço dos vários
fornecedores, o sistema através de critério próprio decidira qual
fornecedor está apto a fornecer. O Fornecedor vencedor é notificado que
foi o vencedor. Em seguida o fornecedor deve realizar a entrega dos
produtos. O sistema deve atualizar a quantidade dos produtos
disponíveis. Após o sistema realizar essa atualização é emitida uma
ordem de pagamento para o fornecedor.

Veja alternativas para Descrição menos informal

7 Procurar Pedido - versão 1

Atores

Fluxo de Eventos Primário (caminho básico):

1. O cliente pode fornecer o número do pedido (NP), a identificação ou

o nome do cliente
2. O cliente ativa “Busca”
3. Se o cliente tiver fornecido o NP
o O sistema devolve o pedido e o caso de uso termina
4. Se o cliente tiver fornecido a identificação ou o nome do cliente
o O sistema mostra a lista com todos os pedidos do cliente
o O cliente seleciona o produto
o O sistema devolve o pedido e o caso de uso termina
Fluxo de Secundário (caminho alternativo):

Se no passo 2, o pedido não foi encontrado, o sistema informa que o

pedido não foi encontrado e solicita que o usuário verifique se os dados
do pedido estão corretos. O caso de uso é encerrado

Pré-condição:

O usuário ter feito o pedido

Pós-condição:

A situação do pedido não ter sido alterada.

Usado por:

2. Verificar Pedido

3. Cancelar Pedido

8 Produto em Oferta - versão 1

Estende

1. Fazer Pedido, antes do passo 5

Fluxo de Eventos Primário (caminho básico):

1 O sistema procura o valor do desconto para o produto

2 O sistema mostra o desconto do produto ao usuário
3 O sistema calcula o valor do desconto
4 O sistema atualiza o total, subtraindo o valor do desconto

Pré-condição:

Produto estar em oferta

Pós-condição:

Valor do desconto calculado

9 Cliente Especial - versão 1

Estende

1. Fazer Pedido, antes do passo 6

Fluxo de Eventos Primário (caminho básico):

1 O sistema procura o valor do desconto para o cliente

2 O sistema mostra o desconto ao cliente
3 O sistema atualiza o total, subtraindo o valor do desconto

Pré-condição:

Cliente ser Cliente Especial

Pós-condição:

Valor do desconto total calculado e subtraído do total de compras

Data Transfer Object

Academicamente, um software é o processo de entrada,

processamento e saída de dados. Sendo uma aplicação
distribuída ou não, precisaremos receber os dados de entrada
(input), que pode originar de uma user interface, chamada
remota, leitura de arquivo… e que de alguma forma, seja ela
uma solução elegante ou não, terá que chegar esses dados no
modelo de domínio, que contém a regra de negócio para
processar, armazenar e por fim, poder fazer o caminho inverso,
resgatando a informação armazenada, processando e exibindo
para o usuário, ou disponibilizando os dados para um outro
processo (output). O pattern Data Transfer Object – DTO, nos
auxilia a passar as informações, por exemplo de uma user
interface para a camada de negócio, e vice-versa. Esse padrão
vem casar com o uso do pattern Facade, já que a para chegar a
camada de domínio, teremos que passar por ela. Pois se a as
entidades de domínio estiverem na própria user interface, não
existindo uma Facade, o uso de objetos Data Tranfer Object não
faz sentido. O que na minha opnião essa aplicabilidade é
precária.
“Data Transfer Object é um objeto que transporta dados entre
processos para reduzir o número de chamadas de métodos”.
Ao invés de termos inúmeros parâmetros nos métodos, ou
realizamos diversas chamadas para as Facades para que
possamos finalizar o processo, criamos um DTO que contém
todas informações necessárias para trabalhamos na interface do
usuário, tendo um outro DTO com parâmetro nos métodos,
reduzindo a quantidade de chamadas para uma Facade,
diminuindo a latência das chamadas e deixando código para
simples de se trabalhar.
A implementação do Data Transfer Object também tem suas
variações, e falar dele é complexo, devido a confusão de nome
feito pela comunidade J2EE com o padrão Value Object – VO,
confusão essa citada no livro do Martim Fowler. Já no site oficial
da Sun, o documentação e aplicabilidade do Data Transfer Object
tem três modos de se implementar. Destaco que os três modos
de se implementar o DTO descrito nos padrões do J2EE, é
diferente do modo no qual o Martin Fowler coloca em seu livro.
Particularmente já utilizei os 2 modos, o citado pelo Fowler e o
citado pelo J2EE.
Talvez a implementação precursora é a do Fowler, de modelar
um DTO para atender uma user interface, de modo que esse
DTO conterá atributos de diversas entidades de negócio. E assim
que essa DTO for enviada para uma Facade, os atributos dessa
DTO será passado para suas respectivas entidades de negócio
(Business Entities). Utilizando o modelo do Core J2EE de DTO por
herança, acredito ter simplificado a implementação e usufruído
do conceito principal.
Implementação de DTO por herança:
Diagramas de sequência UML:
diretrizes
Visual Studio 2015
Outras versões

No Visual Studio, você pode desenhar um diagrama de sequência para

mostrar uma interação.Uma interação é uma sequência de mensagens
entre instâncias típicas de classes, componentes, subsistemas ou atores.
Diagramas de sequência UML fazem parte de um modelo UML e existem
somente em projetos de modelagem UML.Para criar um diagrama de
sequência UML no arquitetura menu, clique em UML novo ou diagrama
de camada.Saiba mais sobre elementos de diagrama de sequência
UML ou diagramas de modelagem UML em geral.Para uma demonstração
em vídeo, consulte esboço interações usando diagramas de sequência
(2010).
Para ver quais versões do Visual Studio oferecem suporte a esse recurso,
consulte Suporte à versão de arquitetura e ferramentas de modelagem.
Neste tópico
Usando diagramas de sequência UML
Etapas básicas para desenhar diagramas de sequência
Criando e usando diagramas de sequência simples
Classes e linhas de vida
Criação de seqüências de interação reutilizáveis
Recolhendo grupos de linhas de vida
Descrever estruturas de controle com fragmentos
Usando diagramas de sequência UML
Você pode usar diagramas de sequência para várias finalidades em
diferentes níveis de detalhes do programa.Ocasiões típicos para um
diagrama de sequência de desenho são os seguintes:
 Se você tiver um diagrama de caso de uso que resume os usuários
do seu sistema e seus objetivos, você pode desenhar diagramas de
sequência para descrever como os componentes principais do
sistema interagem para cumprir a meta de cada caso de uso.Para
obter mais informações, consulte Diagramas de caso de uso UML:
diretrizes.
Se você tiver identificado as mensagens que chegam em uma
interface de um componente, você pode desenhar diagramas de
sequência para descrever como as partes internas do componente
interagem para alcançar o resultado necessário para cada mensagem
recebida.Para obter mais informações, consulte Diagramas de
componente UML: diretrizes.
Desenho de diagramas de sequência tem vários benefícios:
Você pode ver facilmente como as tarefas são distribuídas entre os
componentes.
Você pode identificar padrões de interação que dificultam a atualizar
o software.
Relação com outros diagramas
Você pode usar diagramas de sequência UML junto com outros
diagramas de várias maneiras.
Linhas da vida e tipos
As linhas da vida que desenhar em um diagrama de sequência podem
representar instâncias típicas do componentes ou classes no seu
sistema.Você pode criar linhas de vida de tipos e tipos de linhas de vida e
mostram os tipos em diagramas de classe UML e diagramas de
componente UML.Para obter mais informações, consulte Classes e linhas
da vida.
Tipos de parâmetro
Você também pode descrever em um diagrama de classe UML os tipos de
parâmetros e retornados os valores que foram usados nas mensagens
enviadas entre as linhas da vida.
Detalhes de caso de uso
Um caso de uso representa a meta de um usuário, uma seqüência de
etapas para atingir a meta.A sequência de etapas pode ser descrita de
várias maneiras.Uma opção é desenhar um diagrama de sequência que
mostra as interações entre os usuários e os componentes principais do
sistema.Para obter mais informações, consulte Diagramas de caso de uso
UML: diretrizes.
Etapas básicas para desenhar diagramas de
sequência
Para obter uma lista completa dos elementos em diagramas de
sequência, consulte Diagramas de sequência UML: referência.

Observação

As etapas detalhadas sobre como criar qualquer um dos

diagramas de modelagem são descritas em Editar modelos e
diagramas UML.
Para criar um diagrama de sequência
1. Sobre o arquitetura menu, clique em UML novo ou diagrama de
camada.
2. Em modelos, clique em diagrama de sequência UML.
3. Nomeie o diagrama.
4. Em Adicionar ao projeto de modelagem, selecione um projeto de
modelagem existente na solução, ou criar um novo projeto de
modelagem, e, em seguida, clique em OK.
Um novo diagrama de sequência é exibida com o diagrama de
sequência caixa de ferramentas.A caixa de ferramentas contém os
elementos necessários e conectores.

Para desenhar um diagrama de sequência

1. Arraste linhas da vida (1) do Toolbox para o diagrama para
representar instâncias de classes, componentes, atores ou
dispositivos.

Observação
 Você também pode criar uma linha da vida arrastando uma
classe existente, a interface, o ator ou o componente
deGerenciador de modelos UML para o diagrama.Isso
cria uma linha da vida que representa uma instância do tipo
escolhido.
2. Desenhe mensagens para mostrar como as linhas da vida colaboram
para atingir uma meta específica.
Para criar uma mensagem (3, 4, 6, 7), clique em uma ferramenta de
mensagem.Clique em linha de vida de envio no ponto onde você
deseja que a mensagem para iniciar e clique em linha de vida de
recebimento.
Uma ocorrência de execução (5) aparece na linha de vida de
recebimento.A ocorrência de execução representa um período de
tempo durante o qual a instância está executando um método.Você
pode criar outras mensagens que iniciar a partir de uma ocorrência
de execução.
3. Para mostrar uma mensagem que vem de uma origem de evento
desconhecida (9) ou transmite para destinatários desconhecidos (10),
desenhe uma mensagem assíncrona de ou para o espaço em branco
no diagrama.Essas mensagens são chamadas encontrou
mensagens (9) e mensagens perdidas (10).

Observação

Para mover um grupo de linhas da vida que perdeu ou

encontrou mensagens, siga estas etapas para selecionar as
linhas da vida antes de movê-los: desenhar um retângulo em
torno dessas linhas de vida, ou pressione e segure
o CTRLpressionada enquanto você clica em cada linha da
vida.Se você usar Selecionar tudo ou CTRL+um para
selecionar todas as linhas da vida e, em seguida, movê-los,
qualquer perdida ou localizada anexadas a essas linhas da
vida de mensagens não será movido.Se esse cenário
 ocorrer, será possível mover essas mensagens
separadamente.
4. Desenhe diagramas de sequência para cada mensagem principal
para o mesmo componente ou sistema.
Para alterar a ordem das mensagens
Arraste uma mensagem para cima ou para baixo na sua linha da
vida.Você pode arrastá-lo sobre outras mensagens, ou dentro ou
fora de um bloco de execução.
-ou-
Clique na mensagem e use o seta para cima e para baixo chaves
para ajustar as posições de mensagem.Use SHIFT + seta para
cima e SHIFT + seta para baixo para alterar a ordem das
mensagens.
Para mover ou copiar sequências de mensagem no
diagrama de sequência
1. Do mouse em uma mensagem (3, 4) e, em seguida, clique em cópia.
2. Clique a ocorrência de execução (5) ou uma linha da vida (1) do qual
você deseja que a nova mensagem a ser enviado e, em seguida,
clique em Colar.Novo remetente pode estar em um diagrama
diferente se desejar.
Uma cópia da mensagem e todas as suas mensagens subsidiárias é
adicionada ao final da ocorrência de execução ou até o final da linha
de vida.

Observação

A mensagem colada sempre aparece no final da linha da

vida ou ocorrência de execução.Depois de ter colado,
arraste-o até uma posição anterior.
Para exibir e editar o texto da assinatura de uma
mensagem
A linha de vida de destino deve ser vinculada ou mapeada para tipos
de estar visível para o texto da assinatura.Para realizar essa tarefa,
execute uma das seguintes etapas:
o Clique com botão direito da linha da vida e, em seguida,

escolha Criar classe.

-ou-
o Selecione a linha da vida, pressione F4, e, em seguida,

no propriedades janela, defina a tipo propriedade a um

existente, digite ou especifique o nome de um novo tipo.O
rótulo da mensagem de clique de botão e escolhaoperação
criar.
O texto da assinatura é exibida abaixo do rótulo de
mensagem.Agora você pode editar o texto da assinatura.Para obter
mais informações, consulte Classes e linhas de vida.
Para melhorar o layout de um diagrama de sequência
Clique em uma parte em branco do diagrama e, em seguida, clique
em reorganizar Layout.
Para desfazer a operação, clique em Editar, e, em seguida, clique
em Desfazer.
Para alterar o pacote que possui a interação
1. Em Gerenciador de modelos UML, localize a interação que exibe o
diagrama de sequência.

Observação

A interação não aparecerão no Gerenciador de modelos

UML até que você adicione a primeira linha da vida para o
diagrama de sequência.
2. Arraste a interação no pacote.
-ou-
 A interação de atalho e, em seguida, clique em Recortar.Com o
botão direito do pacote e, em seguida, clique em Colar.
Criando e usando diagramas de sequência
simples
A forma mais simples e mais usadas de diagrama de sequência contém
apenas linhas da vida e mensagens.Um diagrama desse tipo permite
mostrar claramente uma seqüência típica de interações entre objetos em
seu design ou entre seu sistema e seus usuários.Com freqüência, é
suficiente para ajudá-lo a debater e transmitir seu design.
Aqui estão algumas coisas a serem consideradas quando você desenha
um diagrama de sequência simples.
Tipos de mensagem
Há três ferramentas que você pode usar para criar mensagens.
Use o síncrona ferramenta para descrever uma interação na qual o
remetente aguarda o receptor retornar uma resposta (3).
A << retornar >> seta será mostrada no final da ocorrência de
execução.Ele indica o retorno do controle ao remetente.
Use o Asynchronous ferramenta para descrever uma interação na
qual o remetente pode continuar imediatamente sem esperar que o
receptor (4).
Use o criar ferramenta para descrever uma interação na qual o
remetente cria o receptor (8).
Uma mensagem de criação deve ser a primeira mensagem que o
receptor recebe.
Anotando as interações
Para descrever mais detalhes sobre a seqüência, você pode colocar
um comentário em qualquer lugar no diagrama.
Usando Links de comentário, você pode vincular um comentário a vida,
execuções, usos de interação e fragmentos.

Cuidado

Quando você deseja anexar um comentário para um ponto

específico na seqüência, vincule-o a uma ocorrência de
execução, o uso de interação, ou fragmento.Não vinculá-lo a
uma linha da vida, porque nesse caso, ele não permaneça
conectado no ponto correto na sequência.
Use um comentário:
Observe o que foi obtido nos pontos-chave na sequência.Isso ajuda
os leitores vejam os objetivos das interações.
Descreva o objetivo geral de toda a seqüência.Anexar o comentário
para a ocorrência de execução inicial ou deixá-lo desanexada.Por
exemplo, "cliente escolheu itens de menu e tem um preço."
Descreva as responsabilidades de cada linha da vida.Anexe o
comentário para a linha da vida.Por exemplo, "ordenação Manager
coleta opções de menu do cliente."
Observe as exceções ou alternativas que podem ser executadas
como uma alternativa para a sequência típica mostrada.Por exemplo
"cliente pode optar por ignorar o restante dessa sequência."
o Considere o uso de fragmentos como uma alternativa mais

formal para esse tipo de anotação.Consulte descrever

estruturas de controle com fragmentos
Decidindo o escopo do diagrama
É importante saber claramente que o diagrama destina-se a mostrar.
Evento de inicialização
Cada diagrama deve mostrar a sequência de interações que resulta de um
evento de inicialização.Isso pode ser, por exemplo:
Um usuário inicia um caso de uso, por exemplo, abrir a página da
Web para comprar uma refeição.
Uma mensagem de componente de um sistema para outro, por
exemplo, consultando a disponibilidade de itens que um cliente
deseja comprar.
Um evento disparado por uma alteração de estado, por exemplo,
ações de um item cair abaixo do limite.
Nível de detalhe
Diagramas de sequência podem mostrar diferentes níveis de detalhe.Você
pode decidir quase independentemente do nível de detalhes em duas
dimensões separadas:
Linhas da vida podem representar um desses níveis de detalhe:
Objetos no código do programa, que existe ou você está
desenvolvendo.
Componentes ou seus subcomponentes, geralmente omitindo
fachadas, proxies e outros mecanismos de connective.
Seu sistema e atores externos
As mensagens podem representar um desses níveis de detalhe:
Mensagens de software no código do programa, uma API ou
interface da Web.
Transações ou subpropriedades transações, por exemplo, entre os
usuários e o sistema ou entre o código e o banco de dados.
Casos de uso - principais interações entre usuários e o sistema.
Se você está explorando o código existente ou que descreve um novo
design, geralmente é útil desenhar e discutir o menor exibições
detalhadas.
Descrevendo variações
O diagrama mostra uma seqüência simples e típica de eventos.Se você
quiser mostrar possibilidades alternativas como cenários de falha, você
pode usar uma destas opções:
Desenhar diagramas de sequência separada para descrever os
cenários
Use descrevendo as estruturas de controle com fragmentos para
mostrar os loops, alternativas e assim por diante.
Avaliando o Design
Você pode usar o diagrama para avaliar a distribuição de tarefas entre
seus objetos ou componentes.Considere a refatoração se você vir esses
padrões:
Uma linha da vida parece fazer tudo, fazer chamadas para todo o
resto, enquanto as outras linhas da vida apenas respondem
passivamente.
 Muitas mensagens de várias linhas da vida.Cada linha da vida deve
enviar mensagens para apenas alguns vizinhos e não deve se
comunicar com vizinhos de seus vizinhos.Geralmente deve ser
possível organizar as linhas de vida para que haja apenas alguns
lugares onde as mensagens entre linhas de vida; e onde há
cruzamentos, a linha de vida de destino deve não também trocar
mensagens com as linhas da vida transversais.
Parecem que algumas linhas de vida lidar com mais de um tipo de
tarefa.Ele deve fácil localizar uma sentença sucinta que descreve as
responsabilidades de cada linha da vida, resumindo o trabalho em
resposta a cada mensagem que ele recebe.
Classes e linhas de vida
As linhas da vida em seus diagramas de sequência mostram as instâncias
de classes ou interfaces de componentes.Você pode nomear uma linha da
vida de duas maneiras:
Para essa finalidade Use este formato
Anônima instância de um tipo. typeName
Use essa opção se você tiver apenas uma
linha da vida de cada tipo.
Instância nomeada de um tipo. objectName:typeName
Use essa opção se você deseja mostrar
uma sequência que envolve mais de uma
instância do mesmo tipo.
Criando linhas de vida de tipos
Você pode criar novas linhas da vida de classes que já definido, por
exemplo em um diagrama de classe.

Observação

Verifique se que você tem um diagrama de sequência existente

antes de executar essa tarefa.
Para criar uma linha da vida de um tipo existente
Arraste uma classe, componente ou interface do Gerenciador de
modelos UML para um diagrama de sequência.
-ou-
1. Clique a classe, componente ou interface em seu respectivo
diagrama e, em seguida, clique em Criar linha da vida.
2. No Criar linha da vida caixa de diálogo, selecione um
diagrama de sequência e, em seguida, clique em OK.
Será exibida uma nova linha de vida de instância nomeada, cujo tipo
é o tipo que você arrastou.

Observação

Você pode repetir esta ação quantas vezes desejar.Isso

criará a vida com nomes de instância diferente.
Para alterar o tipo de uma linha da vida
1. Clique em uma linha da vida e, em seguida, clique em propriedades.
2. No propriedades janela, defina a tipo propriedade.Você pode
selecionar um tipo no menu suspenso ou digite um novo nome.
Criando Classes de vida
Quando você tiver criado um ou mais diagramas de sequência, você pode
resumir as linhas da vida criando classes ou interfaces deles.
Para criar uma classe ou interface de uma linha da vida
1. Clique com botão direito da linha da vida e, em seguida, clique
em Criar classe ou criar Interface.
Uma nova classe ou interface é exibida no Gerenciador de modelos
UML.
2. Crie operações na classe ou interface para cada mensagem que
recebe a linha da vida:
a. Selecione todas as mensagens que você deseja incluir.
b. Clique em uma das mensagens e, em seguida, clique
em método Create.
A nova classe ou interface possui operações para cada
mensagem selecionada.
 O nome da operação aparece abaixo de cada seta de
mensagem e, no operação propriedade da mensagem.
Se a mensagem incluída parâmetros no formulário "(parameter:
type)", eles aparecerão na lista de parâmetros da operação de
novo.

Observação

Você deve repetir esta etapa se você adicionar novas

mensagens no diagrama de sequência.
3. Para exibir a nova classe ou interface detalhadamente, adicioná-lo a
um diagrama de classe ou componente.
a. Abra ou crie um diagrama de classe ou componente.
b. Arraste a nova classe ou interface de Gerenciador de modelos
UML para um diagrama de classes.
A classe ou interface é exibida no diagrama de classes.
-ou-
c. Arraste a nova interface de Gerenciador de modelos UML em
um componente ou uma porta em um diagrama de
componente.
A interface é exibida no componente como um pirulito.
Criação de classes para parâmetros
Você pode incluir parâmetros nas mensagens em um diagrama de
sequência.Você pode usar um diagrama de classe UML para descrever os
tipos de parâmetro.
Criação de seqüências de interação reutilizáveis
Você pode usar um diagrama separado para descrever uma sequência
que contém detalhes que você deseja separar ou que é comum entre
vários diagramas.
Você pode criar um retângulo de uso da interação (12) em um diagrama
que aponta para os detalhes em outro diagrama.
Clique duas vezes em um uso de interação para abrir o diagrama de
sequência que esteja vinculado a ele.
Para criar uma sequência de interação reutilizáveis de vida
existente
1. No Toolbox, clique em uso da interação.
2. No diagrama de sequência, mantenha o botão do mouse
pressionada enquanto você arrasta entre as linhas de vida que você
deseja incluir na sequência reutilizável.Começa com a posição
vertical onde você deseja inserir o uso de interação.
Aparece um uso da interação entre as linhas da vida selecionadas no
diagrama de sequência.
3. Duas vezes no nome sobre o uso de interação e renomeá-lo para
descrever o efeito da sequência reutilizável no diagrama.
-ou-
Escreva o nome, como uma chamada de função com parâmetros.
4. Vincule o uso de interação a outro diagrama de sequência.Clique o
uso de interação e, em seguida, em:
Clique em Criar nova sequência para criar um novo diagrama de
sequência
-ou-
Clique em Link para sequência para vincular a um diagrama
existente.
Visual Studio cria um vínculo entre o uso de interação e a nova
sequência de interação.
Um novo diagrama de sequência é exibida em sua solução.Ele
contém as linhas de vida que você usou para criar o uso de
interação.

Observação

Somente as linhas da vida usado para criar o uso de

interação será incluídas.O novo diagrama não incluirão
linhas da vida criado após a interação utilizada, mesmo se o
uso de interação abrange-los agora.
Para criar uma sequência reutilizável de mensagens
existentes
Clique a mensagem que você deseja mover e, em seguida, clique
em Mover para diagrama.
Visual Studio:
o Substitui uma interação usa a mensagem selecionada e

quaisquer mensagens subsidiárias.

o Move as mensagens substituídas para um novo diagrama de

sequência.
o Cria um vínculo entre o uso de interação e o novo diagrama de

sequência.
Para navegar até a sequência referenciada por um uso de
interação
Clique duas vezes o uso de interação.
-ou-
O uso de interação de atalho e, em seguida, clique em Ir à
sequência.
Criando um espaço reservado com um uso de interação
Você pode criar uma interação, use sem vinculá-lo a um outro
diagrama.Você pode usar isso como um espaço reservado para uma parte
da sequência cujos detalhes ainda estão para ser resolvidas.Use o nome
do uso de interação para indicar o resultado desejado.
Recolhendo grupos de linhas de vida
Você pode recolher um conjunto de linhas da vida juntos, para que o
grupo é exibido como uma linha da vida.Isso ajuda a visualizar um grupo
de objetos como um único componente.Mensagens e usos de interação
entre linhas de vida de um grupo recolhida ficam ocultos.Mensagens e
sequências de interação que incluem outras linhas da vida são mostradas.
Para recolher um grupo de linhas da vida juntos
1. Selecione duas ou mais linhas da vida.
2. Clique em um deles e, em seguida, clique em Recolher.
As linhas da vida separadas são substituídas por uma única linha da
vida.
 Mensagens e usos de interação que envolvem somente os membros
do grupo estão ocultos.
3. Para renomear o grupo, clique no nome.

Observação

O nome do grupo serão perdido quando você expandir o

grupo.
Para expandir um grupo recolhido
Clique com botão direito da linha da vida recolhida e
clique expandir.

Observação

O nome do grupo será perdida, junto com os links a partir

do grupo para comentários ou itens de trabalho.

Descrever estruturas de controle com

fragmentos
Você pode usar fragmentos combinados (13) para definir loops e
ramificações de processamento simultâneo em um diagrama de
sequência.Como alternativa, considere usar um diagrama de
atividade.Diagrama de atividade não é tão útil mostrar mensagens entre
os atores, mas em alguns casos, é melhor mostrando ramificações, loops
e simultaneidade.
Para obter uma lista completa dos tipos de fragmento, consulte Descrever
o fluxo de controle com fragmentos em diagramas de sequência UML.
Para criar um fragmento combinado
1. Selecione uma mensagem ou uma sequência de mensagens inicial
todos na mesma linha da vida ou ocorrência de execução.
 Observação

Selecione as setas de mensagem, não as ocorrências de

execução que as mensagens apontam para.
2. Uma das mensagens de atalho, aponte para Circundar com, e, em
seguida, clique no tipo de fragmento que você precisa.
Um novo fragmento é exibida.Ele contém as mensagens que você
selecionou.
Se o tipo de fragmento combinado permite vários fragmentos, um
fragmento vazio também será exibida.
3. Para definir a proteção de um fragmento, clique na borda do
fragmento e, em seguida, clique em propriedades.Definir
oGuard propriedade.
O protetor é usado para definir a condição para uma ramificação ou
um loop.
4. Para adicionar um novo fragmento para um tipo que permite que
vários fragmentos, o limite de um fragmento de clique de botão e
aponte para Add.Clique em operando de interação
antes ou operando de interação após.
5. Para adicionar novas mensagens a um fragmento, use as
ferramentas de mensagem, ou copiar e colar.

Atributos

Um atributo é um valor de dado assumido pelos objetos de uma classe. Nome, idade e peso são
exemplos de atributos de objetos Pessoa. Cor, peso e modelo são possíveis atributos de
objetos Carro. Cada atributo tem um valor para cada instância de objeto. Por exemplo, o
atributo idade tem valor ``29'' no objeto Pedro Y.Em outras palavras, Pedro Y tem 29 anos de
idade. Diferentes instâncias de objetos podem ter o mesmo valor para um dado atributo.

Cada nome de atributo é único para uma dada classe, mas não necessariamente único entre todas
as classes. Por exemplo, ambos Pessoa e Companhia podem ter um atributo chamado endereço.

No diagrama de classes, atributos são listados no segundo segmento da caixa que representa a
classe. O nome do atributo pode ser seguido por detalhes opcionais, tais como o tipo de dado
assumido e valor default. A Figura mostra esta representação.
 Figura: Representação diagramática de OMT para classes e objetos com atributos. Um diagrama de classe com atributos é
apresentado à esquerda. Um possível diagrama de instâncias com os respectivos valores é apresentado à direita.

Não se deve confundir identificadores internos de objetos com atributos do mundo real.
Identificadores de objetos são uma conveniência de implementação, e não têm nenhum
significado para o domínio da aplicação. Por exemplo, CIC e RG não são identificadores de
objetos, mas sim verdadeiros atributos do mundo real.

Início de uma Iteração de

Construção
Para iniciar uma iteração, lembre que certos refinamentos
são feitos antes de iniciar a análise detalhada da
funcionalidade desejada na iteração
O capítulo que inicia agora trata de análise, ou da
elaboração de um modelo conceitual
Elaboração de um Modelo Conceitual
Objetivos
Criar um modelo conceitual inicial
Distinguir entre atributos corretos e incorretos
Adicionar conceitos de descrição, quando apropriado
Comparar e contrastar os
termos conceito, tipo, interface e classe

Introdução
O modelo conceitual é o artefato mais importante criado
durante a análise
O modelo conceitual ilustra os conceitos importantes do
domínio do problema, suas associações e atributos
Falaremos de associações e atributos nos próximos
capítulos
Levantar um conjunto rico e expressivo de conceitos
(objetos) durante a análise ajuda muito a conduzir as
fases de projeto e implementação
 É importante lembrar que os conceitos levantados aqui
são do domínio do problema e não conceitos associados a
software

Modelos conceituais
Ao fazer análise OO, a decomposição do domínio do
problema utiliza objetos e não funções ou processos como
na análise estruturada
Exemplo de um modelo conceitual (com conceitos,
associações e atributos)
Apenas a parte diagramática está sendo mostrada
UML permite associar descrições mais detalhadas dos
conceitos, atributos, etc.

Criar o modelo conceitual ajuda a elaborar o glossário,

definindo os termos importantes do domínio do problema
Muito importante para a comunicação entre os
envolvidos (clientes e desenvolvedores)
Modelos conceituais não representam entidades de
software mas conceitos do domínio do negócio
Exemplo correto
 o Exemplos errados

o Cuidado! Alguns profissionais acham correto introduzir

responsabilidades (ou operações) no modelo conceitual
Embora ninguém ache certo introduzir métodos (que
implementam operações) no modelo conceitual

Estratégias para identificar conceitos

(objetos)
Regra fundamental: é melhor ter conceitos demais
(muitos conceitos de granularidade pequena) do que
conceitos de menos no modelo conceitual
Novos conceitos podem ser descobertos com tempo
(quando se está identificando associações ou atributos,
por exemplo) e a elaboração de um modelo conceitual é
portanto uma atividade iterativa
Na modelagem de dados para bancos de dados, há um
critério de modelagem que diz que algo sobre o qual não
precisamos lembrar nada não precisa entrar no modelo
conceitual
Com o ponto de visto de persistência, a regra faz
sentido
Mas na modelagem OO, objetos com apenas
comportamento (sem atributos) também são
importantes (embora raros) e não devem ser excluídos
do modelo
Usando a lista de categoria de conceitos

Conceitos são comumente descobertos nas categorias da

tabela seguinte
Os exemplos são referentes aos domínios de uma loja
e reserva de passagem aérea
Categoria de Conceito Exemplos

Terminal Ponto De Venda (TPDV)

Objetos físicos ou tangíveis
Aeronave

Especificações, projetos ou descrições de Especificação de produto

coisas Descrição de um vôo

Loja
Lugares
Aeroporto

Venda, Pagamento
Transações (um momento notável)
Reserva

Detalhes de transação (Line item) Item de detalhe de uma venda

Caixa
Papeis de pessoas
Piloto

Loja, Prateleira
Coleções de outras coisas (containers)
Aeronave

Item
Coisas dentro das coleções
Passageiro

Sistema de autorização de cartão de

Outros sistemas externos a nosso
crédito
sistema
Sistema de controle de tráfego aéreo

Fome
Conceitos abstratos
Acrofóbia (medo de altura)

Departamento de vendas
Organizações
Voamos Baixo, Ltda.

Venda, Roubo, Reunião

Eventos
Vôo, Desastre, Aterrissagem

Processos (frequentemente não é

Fazer a venda de um produto
representado como conceito, mas pode
Fazer uma reserva de lugar num vôo
ocorrer)
 Política de devolução
Regras e políticas
Política de cancelamento

Catálogo de produtos
Catálogos
Catálogo de peças

Recibo, Plano de contas, Contrato de

Registros de assuntos financeiros, de
emprego
trabalho, de contratos, legais
Log de manutenção

Linha de crédito
Instrumentos e serviços financeiros
Estoque

Manual do empregado
Manuais, livros
Manual de reparos

Achando conceitos através de substantivos

Uma técnica simples para a identificação de conceitos é

de isolar os substantivos nas descrições textuais dos Use
Cases
Muitos dos substantivos serão conceitos ou atributos
Exemplo: Use Case expandida "Comprar Item com
Dinheiro Vivo"
Ação do ator Resposta do sistema

1. O Use Case inicia quando um cliente chega

a um caixamunido de TPDV com itens a
comprar

2. O caixa registra a identificação de 3. Determina o preço do item e adiciona a

cada item informação ao total da transação de venda

Se houver mais itens, o caixa pode A descrição e preço do item corrente são
informar a quantidadetambém exibidos

4. Ao completar a entrada dos itens,

5. Calcula e apresenta o total da venda
o caixa indica este fato ao TPDV

6. O caixa informa o total da venda ao cliente

7. O cliente efetua
o pagamento com dinheiro, possivelmente
maior que o total da venda

9. Mostra o valor do troco ao cliente

8. O caixa registra
a quantidade de dinheiro recebida
Gera um recibo impresso
10.O caixa deposita o dinheiro recebido e
extrai o troco a devolver
11.Faz log da venda completada
O caixa entrega o troco e
o recibo impresso ao cliente

12.O cliente sai da loja com

os itens comprados

Alguns desses substantivos são conceitos (objetos),

outros são atributos de conceitos
Falaremos mais sobre as diferenças em outro capítulo
Uma regra útil: Se pensarmos sobre um conceito X
como número ou texto no mundo real, ele pode ser um
atributo; caso contrário, sempre será um conceito
Na dúvida, crie um conceito separado
Exemplo: Destino é um atributo de um vôo ou um
conceito separado?
É um conceito separado (pensamos no destino
como sendo um aeroporto)

Conceitos candidatos para o domínio do TPDV

Usando as técnicas acima, temos a seguinte relação de
candidatos:
Especificação de
TPDV
produto

Item de detalhe de
Item
uma venda

Loja Caixa

Venda Cliente

Pagamento Gerente

Catálogo de
produtos
Relatórios são objetos?

Um recibo é um relatório
Deveria ser um conceito (objeto)
A favor de excluir:
Um recibo é apenas um relatório de uma venda
Incluí-lo no modelo conceitual não seria útil porque
toda sua informação é derivada de outros objetos
A favor de incluir
Um recibo tem um papel importante nas regras de
negócio porque permite que o cliente devolva itens
comprados
Na primeira iteração de desenvolvimento, os Use Cases
não consideram a devolução do produto e não incluiremos
o objeto Recibo
Em outra iteração, poderá ser incluído

Modelagem do mundo não real

Em certos domínios de problema, os conceitos são muito
abstratos
Exemplo: domínio de redes de computadores ou
telecomunicações
Conceitos possíveis são: Mensagem, Conexão, Diálogo,
Protocolo, etc.

Modelando descrições
Não se deve incluir como atributos descrições de
conceitos a instâncias desses conceitos por dois motivos
Repetição de informação
A descrição some se não houver instância
Exemplo: Não está correto incluir a descrição de um
produto no conceito Produto
É melhor criar um novo conceito DescriçãoDeProduto
que descreve instâncias de Produtos
 Outro exemplo: O conceito Vôo deveria incluir toda a
descrição do vôo?
Não! Se nenhum vôo RG321 ocorrer, a descrição do
vôo RG321 deve continuar em algum lugar: é um
conceito à parte

Termos empregados na UML

UML não emprega a palavra "conceito"
As alternativas são tipo e classe
A diferença entre tipo e classe é que um tipo é abstrato
(sem implementação) enquanto a classe sempre inclui
alguma implementação
Portanto, o tipo é uma especificação e a classe é uma
implementação (de um tipo)
A diferença entre as duas coisas se torna mais
importante durante a fase de Projeto
 Por enquanto, basta dizer que usaremos "conceito" para
falar do domínio do problema e "classe" para falar de
entidades de software
Objetos e Classes

Programação 3: Orientação a Objetos e Java

Anteriormente, consideramos programação

como uma atividade envolvendo três `mundos':
real, computacional e linguístico (ou sintático).
Já somos familiares com os objetos e
classificações do mundo real; resta agora se
familiarizar com os objetos e classes
computacionais e aprender a descrevê-los
(especificá-los) em Java. Aí finalmente
poderemos mapear os objetos reais em objetos
computacionais e escrever programas que dão
vida a estes objetos em um sistema
computacional.
Objetos (computacionais) são caracterizados
por atributos e métodos. Atributos são as
propriedades de um objeto. Métodos são as
ações que um objeto pode realizar.
Naturalmente, os atributos de um objeto podem
mudar de acordo com o tempo. De fato, a
execução de um método muda os valores dos
atributos do objeto responsável pela execução.
Neste caso dizemos que o objeto mudou
de estado.
Atributos podem ser classificados
como derivados ou essenciais (também
chamados armazenados). O valor de um atributo
derivado é determinado em função dos valores
de atributos essencias e de outros atributos
derivados. Por outro lado, o valor de um atributo
essencial é determinado pelo estado interno de
um objeto. Naturalmente, esta classificação
depende das diferentes visões que podemos ter
da realidade.
Classes são agrupamentos de objetos
(computacionais) que têm propriedades em
comum e podem realizar as mesmas ações.
Naturalmente, este agrupamento deve refletir a
classificação natural dos objetos reais. De fato,
classes introduzem a noção de tipo em
linguagens orientadas a objetos, o que é
fundamental para organizar informações e evitar
erros desnecessários. Mais adiante veremos que
temos também a noção de subtipo (subclasse),
a qual está diretamente associada a noção de
subagrupamento (subconjunto). De uma forma
geral, os objetos de uma subclasse têm as
propriedades e ações dos objetos de uma
superclasse e mais algumas propriedades e
ações adicionais.
Para descrever uma classe em uma linguagem
de programação basta descrever os atributos e
métodos dos objetos da classe. De certa forma,
isto poderia ser feito usando-se pacotes de ADA
com mecanismos para esconder informações,
como vimos previamente. No entanto, desta
maneira objetos não são cidadãos de primeira
classe; isto é, não podem ser argumentos ou
resultados de operações, não podem ser
armazenados em variáveis, etc. Todos estes
aspectos são essenciais para programação
orientada a objetos.
Contrastando, Java oferece recursos linguísticos
para resolver estes problemas. De uma maneira
geral, classes são especificadas (descritas) da
seguinte forma em Java:
class NomeDaClasse{
Corpo
}
onde Corpo corresponde à descrição dos
atributos e métodos da classe.
Em particular, atributos essenciais são descritos
da seguinte forma:
class Livro {
private String titulo;
private int anoDePublicacao;
private int numeroDePaginas;
...
}
onde cada atributo tem um tipo específico que
caracteriza as propriedades dos objetos da
classe. Neste caso, int e String denotam os tipos
cujos elementos são inteiros e strings.
A palavra reservada private indica que os
atributos só podem ser acessados (isto é, lidos
ou modificados) pelas operações da classe
correspondente. De fato, alguns autores
consideram isto uma pré-condição para que uma
linguagem seja orientada a objetos. Outros vão
mais adiante, exigindo que os atributos de um
objeto só podem ser acessados pelos métodos
deste objeto; depois será mais fácil entender a
diferença entre estes dois requisitos.
Vários atributos essenciais de um mesmo tipo
podem ser declarados da seguinte maneira:
class Pessoa {
private int anoDeNascimento;
private String nome, sobrenome;
private boolean casado = false;
...
}
Este exemplo também mostra como podemos
especificar que um atributo deve ser inicializado
com um valor específico. Neste caso, o
atributo casado deve ser inicializado com o valor
booleano false toda vez que for criado um objeto
da classe Pessoa.
Podemos ver os atributos essenciais de um
objeto como sendo variáveis locais que
armazenam valores denotando os respectivos
atributos. Assim, atributos essenciais são
usualmente chamados variáveis de instância,
dado que os objetos de uma classe são também
chamados instâncias desta classe.
Atributos derivados são representados por
operações que simplesmente calculam o valor
do atributo e retornam este valor como resultado
da operação. Por exemplo, sabemos que o
século no qual uma pessoa nasceu é um atributo
de Pessoa que pode ser calculado em função do
ano de nascimento desta pessoa. Similarmente,
a idade de uma pessoa também é um atributo
de Pessoa que pode ser calculado a partir do ano
corrente e do ano de nascimento desta pessoa.
Em Java, estes atributos são definidos da
seguinte forma:
class Pessoa {
private int anoDeNascimento;
private String nome, sobrenome;
private boolean casado = false;

int seculoDeNascimento() {
return ...anoDeNascimento...;
}

int idade(int anoCorrente) {

return ...anoDeNascimento...;
}
...
}
onde na definição de cada operação indica-se
primeiro o tipo do valor a ser retornado, seguido
pelo nome da operação e uma lista,
possivelmente vazia, indicando o tipo e o nome
dos argumentos a serem recebidos pela
operação. O comando return especifica o valor a
ser retornado como resultado da operação.
Um tipo trivial de atributo derivado simplesmente
retorna como resultado o valor de um atributo
essencial, como ilustrado a seguir:
class Livro {
private String titulo;
private int anoDePublicacao;
private int numeroDePaginas;
 String titulo() {
return titulo;
}

int anoDePublicacao() {
return anoDePublicacao;
}
...
}
Estes atributos derivados são necessários pois
os valores de alguns atributos essenciais
geralmente devem ser visíveis. Da forma
ilustrada acima, garante-se que os valores de
alguns atributos essenciais podem ser lidos por
clientes (usuários) dos objetos, mas não
diretamente alterados.
Observando que classes são (descritas por) um
tipo especial de módulo e que private é um
mecanismo para esconder informações,
ressalta-se a importância do uso de private para
definir atributos essenciais.
Métodos e Mensagens
Programação 3: Orientação a Objetos e Java
Assim como atributos, métodos são relativos a
uma classe e as suas descrições fazem parte da
descrição da classe. Um método é representado
por uma operação que realiza ações e modifica
os valores dos atributos do objeto responsável
pela execução do método. Em Java, métodos
são especificados da seguinte maneira:
class Conta {
private double saldo;
private long numero;

void credito(double val) {

saldo = saldo + val;
}

void debito(double val) {

saldo = saldo - val;
}
}
onde indica-se primeiro o tipo do valor a ser
retornado pelo método, seguido pelo nome da
método e uma lista, possivelmente vazia,
indicando o tipo e o nome dos argumentos a
serem recebidos pelo método. Usa-se void para
indicar que o método não retorna nenhum valor,
apenas altera os valores dos atributos de um
objeto. Os métodos que retornam valores como
resultado usam o comando return, da mesma
maneira como usa-se este comando para definir
atributos derivados.
Considerando o exemplo acima, a execução do
método debito com argumento 20 altera o saldo
da conta bancária relativa, o qual será
decrementado de 20. De uma forma geral,
métodos são definidos da seguinte maneira:
TipoDeRetorno nomeDoMetodo (Parâmetros) {
Corpo
}
onde Corpo consiste na sequência de comandos
que determinam as ações do método. Estes
comandos podem realizar tanto simples
atualizações dos atributos de um objeto,
conforme ilustrado acima, quanto ações mais
complexas como se comunicar com outros
objetos.
De fato, os objetos de um sistema orientado a
objetos estão sempre se comunicando para
realizar tarefas. Essa comunicação é feita
através da troca de mensagens. Cada
mensagem é uma requisição para que um objeto
execute uma operação específica. Para
requisitar que um objeto obj execute uma
operação op (sem argumentos)
escrevemos obj.op() em Java, o que indica que
durante a execução a mensagem op() será
enviada ao objeto obj.
Por exemplo, podemos especificar que os
objetos da classe Conta se comunicam com a
tela do computador, a qual é representada em
Java por um objeto especial, pré-definido,
chamado `System.out'. Uma das operações que
este objeto pode realizar é println, que mostra
valores passados como argumentos: strings,
inteiros, reais, etc. Para imprimir valores na tela
temos que enviar uma mensagem para
`System.out' requisitando a execução do
método println. Assim, podemos facilmente definir
um método para imprimir o saldo de uma conta,
como ilustrado a seguir:
class Conta {
private double saldo;
private long numero;

void credito(double val) {

saldo = saldo + val;
}

void debito(double val) {

saldo = saldo - val;
}

void printSaldo() {
 System.out.println("Conta: " + numero + " Saldo: R$"
+ saldo);
}
}
Através do método print_saldo, um objeto
de Conta se comunica com a tela do computador.
Na prática, esta comunicação se daria não
em Conta, mas em uma classe que
representasse uma interface de objetos
de Conta com usuários. Note que concatenação
de strings é representada por + e os valores de
outros tipos são automaticamente convertidos
para strings.
Inicializadores
Programação 3: Orientação a Objetos e Java

Além de métodos e atributos, a definição de uma

classe pode incluir também a definição
de inicializadores (também
chamados construtores, apesar de
nãoconstruirem nada!) que são operações que
podem ser utilizadas para inicializar os atributos
dos objetos:
class Conta {
...
Conta (long num, double val) {
numero = num;
 saldo = val;
}
...
}
Inicializadores têm o mesmo nome da classe,
podendo haver mais de um desde que com
número e/ou tipos de argumentos diferentes:
class Conta {
...
Conta (long num, double val) {
numero = num;
saldo = val;
}

Conta (long num) {

numero = num;
saldo = 0.0;
}
...
}
Depois veremos como os inicializadores podem
ser utilizados. Distingue-se entre os vários
inicializadores pela ordem, o tipo e o número de
argumentos fornecidos.

Diagramas de Classe para a Fase de

Projeto
Introdução
Ao completar os diagramas de interação, pode-se
completar o diagrama de classes
Na realidade, o diagrama de classes é criado em
paralelo com os diagramas de interação
No final, falta incluir alguns detalhes finais

Exemplo de um Diagrama de Classes

Diagrama de classes na fase de projeto

 Deve especificar as classes de software e as interfaces da
aplicação
Não somente das entidades conceituais
Informação tipicamente incluída:
Classes, associações e atributos
Interfaces, incluindo métodos e constantes
Métodos
Informação de tipo de atributos
Navegabilidade
Dependências

Como construir um diagrama de classes

1. Identificar todas as classes que participam da solução em
software
o Isso é feito pela análise dos diagramas de interação
2. Inclui-las num diagrama de classes
3. Duplicar os atributos, a partir das entidades associadas no
modelo conceitual
4. Adicionar nomes de métodos descobertos nos diagramas
de interação
5. Adicoonar informação de tipo aos atributos e métodos
6. Adicionar as associações necessárias para a visibilidade de
atributos
7. Adicionar setas às associações para indicar a diração da
visibilidade de atributos
8. Adicionar linhas de relações de dependência para indicar a
visibilidade que não seja de atributo

Modelo conceitual versus diagrama de classes

da fase de projeto
Para ambos, UML usa o diagrama de classes
 No modelo conceitual, uma entidade não representa uma
classe de software mas um conceito do domínio do
problema
No diagrama de classes da fase de projeto, as classes são
de software

Criação dos diagramas de classe do estudo de

caso
Identificar as classes de software

Verificar todos os diagramas de interação para identificar

classes
Adicioná-las ao diagrama de classes, junto com os
atributos
Não precisa incluir classes que não participam da iteração
atual
Adicionar nomes de métodos

Analisar os diagramas de interação para descobrir os

métodos de cada classe
Alguns detalhes sobre métodos
O método create() de UML não aparece em muitas
linguagens, pois é uma chamada a um construtor
Muitas vezes, não se incluem os métodos acessores
(getAtributo() e setAtributo())
Se classes de bibliotecas (ex. Vector em Java) são
mostrados no diagrama, não se precisa mencionar seus
métodos
Pode-se usar a sintaxe da linguagem de programação
final, se desejado

Diagrama até agora:

Adição de informação de tipo
Este passo é opcional
Se o diagrama de classes está sendo criado numa
ferramenta CASE (ex. Rational Rose), e a ferramenta
será usada para gerar código, todos os detalhes de
tipos devem ser dados
Se o diagrama for preparado apenas para leitura por
desenvolvedores, o nível de detalhamento pode ser
menor
O seguinte diagrama contém toda a informação de tipo

Adicionar Associações e Navegabilidade

A navegabilidade implica visibilidade da fonte para o
destino
Normalmente navegabilidade de atributo, incluída na
implementação
As associações devem ser apenas aquelas necessárias
para a visibilidade de objetos
Isso é diferente das associações no modelo conceitual,
as quais podem ser incluídas para melhorar o
entendimento
Os diagramas de interação são usados para descobrir a
visibilidade, associações e navegabilidade
Situações comuns que levam a associações:
A envia uma mensagem a B
A cria uma instância de B
A deve manter conhecimento de B
Exemplo:

Diagrama de classes até agora:

Adição de relações de dependência
Quando uma classe conhece outra (tem visibilidade), mas
a visibilidade não é de atributo, usa-se uma linha
tracejada
Exemplo: TPDV recebe um objeto da classe
EspecificaçãoDeProduto como retorno do método
especificação da classe TPDV
Diagrama de classes com dependências:
Incluindo detalhes de membros de classes
UML possui sintaxe para especificar:
Visibilidade
Valores iniciais
etc.
Exemplo:
Padrões e Princípios para
desenvolvimento de interfaces
16 de dezembro de 2009 em Geral.
Com o objetivo de medir a eficiência das
interfaces e sistemas, utilizamos inúmeras
técnicas de avalição, entrevistas e testes de
usabilidade. Mas sabemos que nem sempre
um projeto tem tempo e verba suficientes
para aplicarmos todos esses métodos.
Um dos recursos que podemos utilizar como
um guia de boas práticas desde a fase de
desenvolvimento da interface são as 8
Regras de Ouro de Ben Shneiderman e
as 10 Heurísticas de Nielsen, normalmente
usadas como referência em técnicas de
avaliação.
Jacob Nielsen descreve a avaliação
heurística (uma das técnicas de avaliação)
como um método rápido, barato e fácil de
avaliar o design de uma interface. Este
método deve dispor de 3 a 5 especialistas
que farão suas avaliações individualmente,
que depois serão comparadas gerando um
relatório. Os problemas encontrados serão
classificados em níveis de gravidade e
tabulados. Dessa forma é possível conseguir
uma visão geral dos problemas mais graves
e que devem ser corrigidos prioritariamente.
Para ganharmos tempo e adotarmos um
padrão de qualidade, podemos adotar esses
princípios desde a fase em que estamos
desenhando os fluxos, interfaces e
interações. Certamente o produto será muito
mais eficiente ao cliente e, ao mesmo tempo,
poupará inúmeros ajustes que só seriam
descobertos na fase de avaliação.
Abaixo, seguem as 8 Regras de Ouro de
Ben Shneiderman e as 10 Heurísticas de
Nielsen. Baseado nelas, você pode refinar
seu próprio checklist para desenvolvimento
ou avaliação e ter entregas rápidas com
qualidade.
8 Regras de Ouro de Ben Shneiderman
1. Mantenha a consistência
Sequências consistentes de ações devem
ser usadas em situações similares. Use
terminologia idêntica em prompts, menus e
telas de ajuda. Comandos devem ser
utilizados da mesma maneira ao longo da
interface.
2. Ofereça atalhos aos usuários
experientes
Ao mesmo tempo que a frequência de uso
de uma interface aumenta, o desejo do
usuário é reduzir o número de interações e
aumentar o compasso da interação.
Abreviações, teclas de função, comando
ocultos e facilidades de macros ajudarão o
usuário mais experiente.
3. Ofereça feedbacks informativos
Para cada operação do usuário deve haver
algum tipo de feedback do sistema. Ofereça
respostas discretas quando as ações são
frequentes ou de menor importância e
respostas com maior prioridade para ações
incomuns ou mais importantes.
4. Apresente as etapas do processo
Sequências de ações devem ser
organizadas em grupos com início, meio e
fim. O feedback informativo ao completar um
grupo de ações dá ao usuário satisfação de
realização, senso de distinção e uma
indicação que o caminho é claro para se
preparar para o próximo conjunto de ações.
5. Ofereça uma forma simples de
correção de erros
Tanto quanto possível, o design do sistema
não deve permitir que o usuário cometa
erros graves. Se um erro for cometido, o
sistema deve ser capaz de detectar e
oferecer um mecanismo simples e
compreensível para a solução.
6. Permita fácil reversão de ações
Esta funcionalidade diminui a ansiedade,
desde o momento que o usuário toma
conhecimento que um erro grave pode ser
desfeito. Isso potencializa a exploração de
funções desconhecidas. As unidades de
reversibilidade podem ser de uma única
ação, de uma entrada de dados ou uma
sequência completa de ações.
7. O controle do sistema é do usuário
Usuários experientes desejam ter a noção de
que controlam o sistema e este é que
responde aos seus comandos. O sistema
deve ser projetado para deixar os usuários
como iniciadores das ações ao invés de
reagentes.
8. Reduza a carga de memória curta do
usuário
Este princípio está relacionado à limitação
humana de processamento de informação na
memória de curta duração. O sistema deve
ser projetado para que haja o menor esforço
possível do usuário em memorizar ou
relacionar elementos na interface.
Heurísticas de Nielsen
1. Visibilidade do status do sistema
O sistema deve manter o usuário sempre
informado sobre o que está acontecendo
através de um feedback em tempo real.
2. Correspondência entre o sistema e o
mundo real
O sistema deve usar a linguagem e modelo
mental do usuário e não ser orientado a
estrutura do sistema.
3. Liberdade e controle do usuário
Usuários frequentemente cometem erros e
precisarão ser capazes de reconhecerem
„saídas de emergências‟ para se
recuperarem de estados indesejáveis.
4. Consistência e padrões
Em ações e contextos iguais use as mesmas
palavras, ícones e comportamentos. Facilite
o reconhecimento do usuário.
5. Prevenção de erros
Mais importante que uma boa mensagem de
erro é um design cuidadoso que evita o
problema. Em ações como a de exclusão de
um arquivo, por exemplo, forneça uma
mensagem de confirmação antes da ação
ser executada.
6. Reconhecimento ao invés de
memorização
Evite a sobrecarga de memória do usuário.
Forneça informações contextuais para que
cada ação não precise de informações que
estão em outro ponto do sistema.
7. Flexibilidade e eficiência de uso
Forneça atalhos para usuários experientes
que agilizem o uso deste perfil, mantendo a
facilidade para usuários leigos.
8. Estética e design minimalista
O diálogo do sistema com o usuário não
deve conter informações desnecessárias.
Mantenha apenas as informações úteis,
diretas e claras.
9. Ajude os usuários a reconhecerem,
diagnosticarem e recuperarem-se de
erros
As mensagens de erro devem ser claras a
ponto de indicarem o problema e sugerirem
uma solução.
10. Ajuda e documentação
Embora o melhor é o usuário ser capaz de
usar o sistema sem necessidade de ler a
documentação, é necessário fornecer ajuda
documentada em caso de necessidade. As
informações devem ser facilmente
encontradas, descreverem passos de forma
clara e não serem extensas demais