ENGENHARIA DE REQUISITOS

Anlise de pacote
Categorizao uma parte importante da Modelagem de Anlise.

Engenharia de Requisitos leva um melhor entendimento:

do impacto do software no negcio.

do que o cliente quer

como os usurios finais interagiro com o software.

ER um amplo espectro de tarefas e tcnicas que levam a um entendimento dos requisitos. uma
ponte para o Projeto e Construo: contexto do trabalho de software, necessidades especficas de
projeto e construo, prioridades e ordem de trabalho, dados que impactam no projeto.
ER:

Entender o que o cliente deseja

Analisar necessidades

Avaliar viabilidade

Negociar soluo razovel

Especificar soluo sem ambiguidades

Validar especificao

Gerenciar as necessidades transformadas em sistema

Participam da engenharia de Requisitos:

Eng. software

Analistas

Interessados (gerente, clientes, usurios finais).

Abrange 7 tarefas distintas: (algumas em paralelo, todas adaptveis).

Concepo:
o Escopo e natureza do problema.

o Pessoas envolvidas
o Natureza da soluo
o Eficcia

Comunicao

Colaborao

Levantamento:
o Definir o que necessrio.
o Problemas:

Escopo: limites definidos precariamente, clientes definem detalhes tcnicos

desnecessrios.

Entendimento: clientes com entendimento inadequado e incompleto, com

problemas para transmitir, omitem informaes importantes, requisitos
conflitantes entre usurios/clientes.

Volatilidade: requisitos so mutveis.

Elaborao: requisitos bsicos so refinados e modificados.

o Modelo de requisito refinado: aspectos funcionais do sistema.
o Refinamento de cenrios

Sintaticamente analisados para extrair classes de anlise (entidades de

domnio do negcio visveis ao usurio final).

Cada classe ter atributos, relaes e servios definidos.

Diagramas suplementares so elaborados.

Negociao: conciliar conflitos;

o Clientes e usurios (e outros) ordenem os requisitos por prioridade;

Especificao: documento com descrio detalhada de todos os aspectos do software antes

de o projeto comear.
o SRC com sumario

Validao: avaliar artefatos para qualidade

o Exame de especificao
o Principal mecanismo de validao

Reviso Tcnica: busca de erros no contedo ou na interpretao.

Formada por:

o Engenheiros
o Clientes
o Usurios

Lista de Controle (memorizar perguntas)

Gesto: conjunto de atividades da equipe de projeto para identificar, controlar e acompanhar

necessidades de mudanas enquanto o projeto segue.

Artefatos: cenrio de uso, lista de funo, modelos de anlise, etc.

ENGENHARIA DE REQUISITOS
um conjunto de tarefas que levam a um entendimento de qual ser o impacto do software sobre o
negcio, o que o cliente quer e como os usurios finais iro interagir com o software.
Se inicia na comunicao e continua na modelagem.
Ponte para o projeto e para construo.
Fornece o mecanismo para as necessidades, avaliando a viabilidade, negociando uma
soluo razovel, especificando a soluo sem ambiguidades, validando a especificao.
CONCEPO: define o escopo, entendimento bsico do problema e natureza do problema a ser
resolvido, os envolvidos e a eficcia da comunicao entre eles.
LEVANTAMENTO: o que necessrio, o que deve ser alcanado, como ser o usado o produto.
Problemas: escopo (limites mal definidos), problemas de entendimento e volatilidade (requisitos
mutveis).
ELABORAO: requisitos bsicos refinados informao, funo e comportamento. Refinamento
dos cenrios de uso por usurios, extraindo classes de cada cenrio, cada classe com seus atributos e
servios. Identificadas as relaes e colaboraes entre classes e expressas em diagramas.
NEGOCIAO: prioridades, o que e quando necessrio. Conciliar conflitos de necessidades,
dando s partes certo grau de satisfao.
EXPECIFICAO: documento (grfico, conjunto de cenrios, prottipo) que tem verso detalhada
do software a ser construdo. Pode ser um SRS (software requirements specification).
VALIDAO: problema especificado, revisado e validado quanto qualidade por Reviso Tcnica,
Lista de Controle de Validao de Requisitos.
GESTO: atividades para identificar, acompanhar e controlar mudanas e necessidades durante o
projeto. Pode ser Gerencia de Configurao de Software.
importante notar que algumas delas ocorrem em paralelo e todas so adaptadas s necessidades
do projeto.

INCIO DO PROCESSO DE SOFTWARE

Identificao dos interessados (Lista).

Reconhecimento de diversos pontos de vista.

Colaborao.

Pontos de prioridade (modo de resolver requisitos conflitantes).

So feitas Perguntas Iniciais: responsvel, opes de soluo, problemas, ambiente de negcio,

perguntas de engenheiro;
Levantamento de Requisitos (Elicitao de requisitos).
Resoluo de problemas, elaborao, negociao e especificao para uma abordagem
colaborativa.
Coleta colaborativa de requisitos:

Reunies (com regras e facilitador).

Compreenso do fluxo de eventos: breve cenrio com sequncia de eventos que gera
reunio, ocorrem durante e aps a reunio.

Na concepo gerado o artefato Solicitao de Produto, distribudo a todos da reunio.

Cada participante faz uma lista de objetos (descrio funcional), que ser combinada,
reduzida ou aprimorada.

Crticas so proibidas.

Miniespecificaes da lista de objetos: gera caso de uso, servios, restries e/ou outros
requisitos.

Lista de questes pendentes.

O ER tem como artefatos: declarao de necessidade e viabilidade, escopo do sistema, lista de

clientes e usurios participantes do ER, descrio tcnica do ambiente, requisitos e domnio das
restries, conjunto de cenrios de uso, prottipos.
QUALITY FUNCTION DEPLOYMENT (QFD)
QFD uma tcnica de qualidade para traduzir as necessidades do cliente em requisitos tcnicos.
Maximiza a satisfao do cliente usando ES. Tem 3 necessidades: requisitos normais (objetivos
estabelecidos); requisitos esperados (requisitos implcitos); requisitos fascinantes (recursos alm da
expectativa do cliente).
Usa entrevistas, pesquisa e exame de dados para engenharia de requisitos, extraindo os requisitos
esperados e tentando obter os fascinantes.
Pode utilizar de pesquisas, entrevistas, dados histricos para criar a tabela de requisitos.
CASOS DE USO

Descreve o comportamento em resposta a uma solicitao de um interessado. Representa o software

ou sistema. Conta um histria (texto, esquema, descrio) sobre como o usurio interage com o
sistema em circunstncias especficas.
MODELO DE ANLISE
descrio dos domnios de informao funcional e comportamental. modificado/aprimorado a
medida que se entende melhor o sistema. dito que o Modelo de Anlise uma foto dos requisitos
em um determinado momento.
Diferentes abordagens de representao do Modelo aumenta a probabilidade de descobrir omisses,
inconsistncias e ambiguidade.
Modelos de Anlise genricos possui elementos baseados em:

Cenrios

Classes
o Conjunto de objetos (com comportamentos e atributos) manipulados durante
interao.

Comportamentais
o Formas de representar os estados e comportamentos do sistema
o Utiliza diagrama de estado

Orientados a fluxos
o Informaes transformadas medida que fluem.]

Diagrama de Estado usado para representar o comportamento de um sistema atravs de diviso

dos possveis estados e eventos que causam mudana no sistema. Estado qualquer modo de
comportamento externamente observvel. O Diagrama de Estado indica aes tomadas como
consequncia de um evento.
VALIDAO DE REQUISITOS
Examinar requisitos em termos de inconsistncia, omisses e ambiguidade.
Os requisitos representados pelo modelo so priorizados pelos interessados e agrupados em pacotes
de requisitos que sero implementados como incrementos de software.
Reviso do modelo de requisitos:

Consistncia com os objetivos globais.

Nveis de abstrao (detalhamento tcnico apropriado).

Necessidade/importncia.

Limitao, conflitos e ambiguidade controlados.

Requisitos possvel de implementao no ambiente de desenvolvimento e/ou sistema.

Possibilidade de teste do requisito.

Atendimento forma de informao, funo e comportamento do produto.

Uso dos padres de requisitos e atendimento a estes.

BASE PARA O ENTENDIMENTO DOS REQUISITOS DE SOFTWARE

Processo de Engenharia de Requisitos
1

Quais so os interessados? Qualquer um que se beneficia do sistema. Faz-se listas das

pessoas que faro sugestes e crticas.

Reconhecer todos os pontos de vista e classificar as informaes controlando conflitos.

Trabalhar buscando colaborao: Pontos de prioridade para importncia de necessidades.

Perguntas iniciais
a

As primeiras devem ser livres de contexto com foco no cliente, nos benefcios e nas
metas globais do projeto.
o Quem est por trs da solicitao deste trabalho?
o Quem ir usar a soluo?
o Qual ser o beneficio econmico de uma soluo bem-sucedida?
o H outra fonte para a soluo que voc precisa?

Perguntas para maior entendimento do problema:

o Qual um bom resultado de sada se a soluo for boa?
o Qual problema a soluo trata?
o Onde a soluo trata o problema em termos de ambiente?
o Restries e desempenho altera a abordagem da soluo?

Eficcia da comunicao:
o Voc a pessoa correta para responder? oficial sua resposta?
o Essas perguntas so relevantes?
o muita pergunta?
o Algum tem informaes adicionais?
o Tem algo mais que voc acha que eu deveria perguntar?

Levantamento (elicitao) de Requisitos

Combinao de elementos de problemas, elaborao, negociao, especificao.
feita coleta coletiva de requisitos:

Reunio com todos interessados

Facilitador: regras de participao e preparao

Agenda formal com pontos, mas encorajar fluxo de ideias

A meta identificar o problema, propor elementos da soluo, negociar diferentes abordagens e

especificar um conjunto preliminar de requisitos da soluo em uma atmosfera que seja propcia
para o cumprimento da meta. Para melhor compreender o fluxo de eventos medida que ocorrem,
apresentado um breve cenrio, que descreve em linhas gerais a sequncia de eventos, que levam a
uma reunio para levantamento de requisitos e que acontecem durante e aps a reunio.
realizada durante a concepo.
feita uma solicitao de produto pelo desenvolvedor e o cliente, com data, hora, local de
reunio, facilitador, membros da equipe, que deve ser entregue antes da reunio. So pedidas listas
de objetos constantes e servios que manipulam/interagem com esses objetos, alm de listas de
restries (custo, dimenses, regras) e critrios de desempenho (velocidade, preciso, aparncia).
Nesse momento no h espao para crticas antes da reunio. Esses dados so expostos de alguma
forma: site, mural, fixado em parede.
feita uma lista combinada sem se retirar nada. Conter redundncias, ambiguidades e
discrepncias. Ento reduzida ou ampliada, para ser consensual. Caso um objeto necessite de
maior explicao, cria-se miniespecificaes, que sero lapidadas em discusses.
Cenrios de Uso
So os Casos de Uso, usados para se entender como funes e caractersticas do software sero
usadas por diferentes classes de usurios. Pode se criar um conjunto de cenrios como roteiro de
uso.
Artefatos produzidos: (todos revisados por todos que participaram do levantamento)

Uma declarao da necessidade e viabilidade.

Uma declarao restrita do escopo para o sistema ou produto.

Uma lista de clientes, usurios e outros interessados que participaram do levantamento de

requisitos.

Uma descrio do ambiente tcnico do sistema.

Uma lista de requisitos (preferencialmente organizada por funo) e as restries de domnio

que se aplicam a cada uma delas.

Um conjunto de cenrios de uso que esclarecem o uso do sistema ou produto sob diferentes
condies operacionais.

Quaisquer prottipos desenvolvidos para melhor definio dos requisitos.

CASOS DE USO
Descreve o comportamento em resposta a uma solicitao de um interessado. Conta um histria
Primeiro passo definir o conjunto de atores: qualquer coisa externa que se comunica com o
sistema. Define-se meta do ator, precondies, funes e tarefas do ator, excees e variaes

possveis, informaes acessadas, modificadas ou produzidas pelo ator, quais avisos so visuais ao
ator em caso de mudanas inesperadas.
Caso de uso bsico: histria detalhada de interao.
Exemplo:
CASO DE USO:

DISPONIBILIDADE:

ATOR PRIMRIO:

FREQUENCIA DE USO:

META DO CONTEXTO:

CANAL COM O ATOR:

PRECONDIES:

ATORES SECUNDRIOS:

CENRIO:

CANAL COM SECUNDRIOS:

EXCEES:

QUESTES EM ABERTO:

PRIORIDADE:

CAPTULO 6
MODELAGEM DE REQUISITOS
O Modelo de Requisitos a primeira representao tcnica de um sistema.
A Anlise de Requisitos resulta na especificao de caractersticas operacionais do
software, indica a interface do software com outros elementos do sistema e estabelece
restries que o software deve atender.
A ao da modelagem de requisitos resulta em um ou mais dos seguintes tipos de
modelos:
Modelos baseados em cenrios de requisitos do ponto de vista de vrios "atores" do
sistema.
Modelos de dados que representam o domnio de informaes para o problema.
Modelos orientados a classes que representam classes orientadas a objetos (atributos
e operaes) e a maneira por meio da qual as classes colaboram para atender aos
requisitos do sistema.
Modelos orientados a fluxos que representam os elementos funcionais do sistema e
como eles transformam os dados medida que percorrem o sistema.
Modelos comportamentais que representam como o software se comporta em
consequncia de "eventos" externos.
Tais modelos do informaes traduzidas em projetos de arquitetura, de interfaces e de
componentes.
O modelo de requisitos (e a especificao de requisitos de software) fornecem ao
desenvolvedor e ao cliente os meios para verificar a qualidade to logo o software seja
construdo.
Na modelagem de requisitos, o foco primrio no que e no no como.
Que interao? Qual circunstncia? Quais objetos o sistema manipula? Que funes o
sistema deve executar? Quais comportamentos o sistema apresenta? Que interfaces so
definidas? Quais restries se aplicam?
Objetivos Primrios:
(1) descrever o que o cliente solicita.
(2) estabelecer uma base para a criao de um projeto de software.
(3) definir um conjunto de requisitos que possa ser validado assim que o software for
construdo.

O Modelo de Anlise preenche a lacuna entre uma descrio sistmica que descreve o
sistema como um todo ou a funcionalidade de negcio que atingida aplicando-se
software, hardware, dados, pessoal e outros elementos de sistema e um projeto de
software que descreve a arquitetura, a interface do usurio e a estrutura em termos de
componentes do software.
Todos os elementos do modelo de requisitos esto diretamente associados a partes do
modelo do projeto.
Nem sempre possvel estabelecer uma clara diviso das tarefas de anlise e de projeto
entre essas duas importantes atividades de modelagem.
Algum projeto ocorre invariavelmente como parte da anlise e alguma anlise ser
realizada durante o projeto.
Regras prticas para a anlise:
O modelo deve enfocar as necessidades visveis no domnio do problema ou do
negcio. O nvel de abstrao deve ser relativamente elevado.
Cada elemento do modelo de requisitos deve contribuir para o entendimento geral dos
requisitos de software e fornecer uma viso do domnio de informao, funo e
comportamento do sistema.
Consideraes de infraestrutura devem ser consideradas apenas depois da anlise do
domnio do problema ter sido completada.
Minimize o acoplamento do sistema. importante representar os relacionamentos
entre as classes e funes. Entretanto, se o nvel de "interconexo" for extremamente
alto, deve-se esforar para reduzi-lo.
O modelo de requisitos deve agregar valor a todos os interessados da equipe de
software.
KISS
Anlise de domnio
Usando as fontes de domnio de conhecimento (aplicaes existentes, literatura tcnica,
experts, requisitos j estabelecidos) gera-se a Anlise de Domnio (taxonomia de
classes, padres de reutilizao, modelos funcionais, linguagens de domnio), que
posteriormente gerar um Modelo de Anlise de Domnio.
O objetivo da Anlise de Domnio criar/encontrar Classes de Anlises e Padres de
Anlise que so amplamente aplicados para reutiliz-los.
A aplicao de padres de projeto e de componentes de software executveis melhora o
tempo de colocao do produto no mercado e reduz custos de desenvolvimento. A
anlise de domnio define como esses padres e as classes de anlise so inicialmente

reconhecidos, quem os define, os classifica e os prepara para uso em projetos

subsequentes.
Anlise de domnio de um software so a identificao, a anlise e a especificao de
requisitos comuns de um campo de aplicao especfico, tipicamente para reutilizao
em vrios projetos dentro deste campo de aplicao.
Anlise de domnio orientada a objetos possui mesma definio em termos de objetos,
classes, componentes e frameworks comuns.
Anlise de domnio uma atividade contnua da engenharia de software que no est
ligada a nenhum projeto de software especfico.
O papel da Anlise de Domnio descobrir e definir padres de anlise, classes de
anlise e informaes relacionadas que possam ser usados por vrias pessoas que
trabalham em aplicaes similares, mas no necessariamente as mesmas. Pode ser vista
como umbrela activities.

A Anlise de domnio procura por padres similares nas aplicaes que fazem os
mesmos tipos de coisas do que a que estou construindo. Se possvel, os reutiliza em seu
trabalho.
Abordagens Modelagem de Requisitos
Anlise estruturada: na modelagem de requisitos, considera os dados e os processos que
transformam os dados em entidades separadas. Os objetos de dados so modelados de
maneira que definam seus atributos e relacionamentos. Processos que manipulam
objetos de dados so modelados de maneira que mostrem como transformam dados
medida que os objetos de dados trafegam pelo sistema.
Anlise orientada a objetos: na modelagem de anlise, se concentra na definio de
classes e na maneira pela qual colaboram entre si para atender s necessidades dos
clientes. A UML e o Processo Unificado so predominantemente orientados a objetos.
No h uma melhor abordagem: a combinao de representaes dar aos interessados o
melhor modelo de requisitos de software e a ponte mais efetiva com o projeto de
software.
Cada elemento do Modelo de Requisitos apresenta o problema segundo um ponto de
vista:

Os elementos baseados em cenrios representam como o usurio interage com o

sistema e a sequncia especfica de atividades que ocorre medida que o
software utilizado.

Os elementos baseados em classes modelam os objetos que o sistema ir

manipular, as operaes que sero aplicadas aos objetos para efetuar a
manipulao, os relacionamentos (alguns hierrquicos) entre os objetos e as
colaboraes que ocorrem entre as classes definidas.

Os elementos comportamentais representam como eventos externos mudam o

estado do sistema ou as classes que nele residem.

Os elementos orientados a fluxos representam o sistema como uma

transformao de informaes, indicando como os objetos de dados so
transformados medida que fluem pelas vrias funes do sistema.

A Modelagem de Anlise leva obteno de cada um desses elementos. Entretanto, o

contedo especfico de cada elemento (os diagramas usados para construir o elemento e
o modelo) pode diferir de projeto para projeto. Devem ser utilizados apenas aqueles
elementos da modelagem que agregam valor ao modelo.
Modelagem Baseada em Cenrios
Entender como os usurios finais (e outros atores) querem interagir com um sistema,
sua equipe caracterizar, de maneira apropriada, os requisitos e a construir modelos de
anlise e projeto proveitosos.
A Modelagem de Requisitos com UML comea com a criao de cenrios na forma de
casos de uso, diagramas de atividades e diagramas de reais.
Sobre o que escrever?
As fases de Concepo e Levantamento nos fornecem informaes necessrias para
comearmos a escrever casos de uso. As reunies para levantamento de requisitos, o
QFD e outros mecanismos de engenharia de requisitos so utilizados para identificar
interessados, definir o escopo do problema, especificar as metas operacionais globais,
estabelecer as prioridades, descrever todos os requisitos funcionais conhecidos e
descrever os itens (objetos) manipulados pelo sistema.
Para comear a desenvolver um conjunto de casos de uso, enumere as funes ou
atividades realizadas por um ator especfico. Podemos obt-las de uma lista de funes
dos requisitos do sistema, por meio de conversaes com interessados ou atravs de
uma avaliao de diagramas de atividades desenvolvidas como parte da modelagem de
anlise.
medida que as conversaes com o interessado forem avanando, a equipe de
levantamento de requisitos desenvolve casos de uso para cada uma das funes citadas.

Em geral, os casos de uso so escritos primeiro de forma narrativa informal. Caso seja
necessria maior formalidade, o mesmo caso de uso reescrito usando um formato
estruturado e reproduzido mais adiante.
So usados casos de uso de forma narrativa e linear, de forma sequencial numerada.
Recomenda-se o uso de uma sesso de brainstorming para obter um conjunto de
excees relativamente completo para cada caso de uso.
O cenrio enumera as aes especficas que o ator deve tomar e as respostas apropriadas
do sistema. As excees identificam as situaes reveladas medida que o caso de uso
preliminar refinado. Cabealhos adicionais podero ou no ser acrescentados e so
relativamente autoexplicativos.
Em muitos casos, no h nenhuma necessidade de criar uma representao grfica de
um cenrio de uso. Entretanto, a representao diagramtica pode facilitar a
compreenso, particularmente quando o cenrio complexo.
Cada caso de uso representado por uma elipse em UML.
Toda notao de modelagem tem suas limitaes, e o caso de uso no uma exceo.
Assim como qualquer outra forma de descrio escrita, a qualidade de um caso de uso
depende de seu(s) autor(es). Se a descrio no for clara, o caso de uso pode ser
enganoso ou ambguo.
Um caso de uso que se concentra nos requisitos funcionais e comportamentais
geralmente inapropriado para requisitos no funcionais. Para situaes em que o
modelo de anlise deve ter muitos detalhes e preciso (por exemplo, sistemas com
segurana crtica), um caso de uso talvez no seja suficiente.
Entretanto, a modelagem baseada em cenrios apropriada para a grande maioria de
todas as situaes com as quais voc ir deparar como engenheiro de software. Se
desenvolvido apropriadamente, o caso de uso pode gerar grandes benefcios como
ferramenta de modelagem.
UML diagrama de atividade
Complementa o caso de uso atravs de uma representao grfica do fluxo de interao
em um cenrio especfico. Similar ao fluxograma, um diagrama de atividades usa
retngulos com cantos arredondados para representar determinada funo do sistema,
setas para representar o fluxo atravs do sistema, losangos de deciso para
representar uma deciso com ramificao (cada seta saindo do losango identificada) e
as linhas horizontais cheias indicam as atividades paralelas que esto ocorrendo.
Diagramas de atividades acrescentam outros detalhes no mencionados (mas implcitos)
pelo caso de uso.

O Diagrama de Raias UML uma til variao que representa o fluxo de atividades e
ao mesmo tempo indica qual ator (se existirem vrios atores envolvidos em determinado
caso de uso) ou classe de anlise tem a responsabilidade pela ao descrita por um
retngulo de atividade.
Casos de uso, juntamente com os diagramas de
atividades e de raias, so orientados a
procedimentos. Eles representam a maneira
pela qual vrios atores chamam funes
especficas (ou outras etapas procedurais) para
atender aos requisitos do sistema. Porm, uma
viso procedural dos requisitos representa
apenas uma nica dimenso de um sistema.

CONCEITOS DE MODELAGEM DE DADOS

Pela necessidade de criar, estender ou interfacear com um banco de dados ou se as
estruturas de dados complexas tiverem de ser construdas e manipuladas, optar-se por
um modelo de dados como parte da modelagem de requisitos.
Um analista ou engenheiro de software define todos os objetos de dados processados no
sistema, os relacionamentos entre os objetos de dados e outras informaes pertinentes
aos relacionamentos.
*****em qual etapa criado o modelo de dados?
O Diagrama Entidade-Relacionamento (Entity-Relationship Diagram) trata das
questes e representa todos os objetos de dados introduzidos, armazenados,
transformados e produzidos em uma aplicao.
OBJETO DE DADOS uma representao das informaes compostas que devem ser
compreendidas pelo software. Por informao composta, entende-se algo que tenha uma
srie de propriedades ou atributos diferentes.
A largura (um nico valor) no seria um objeto de dados vlido, mas dimenses
(incorporando altura, largura e profundidade) poderiam ser.
Exemplos de objeto de dados:

entidade externa (por exemplo, qualquer item que produza ou consuma

informaes)

uma coisa {por exemplo, um relatrio ou uma exibio),

uma ocorrncia (por exemplo, uma ligao telefnica) ou evento (por exemplo,
um alerta),

um papel (por exemplo, vendedor),

uma unidade organizacional (por exemplo, departamento de contabilidade),

um local (por exemplo, um armazm) ou uma estrutura (por exemplo, um

arquivo).

Um objeto de dados encapsula apenas dados no h nenhuma referncia em um

objeto de dados a operaes que atuam sobre os dados.
Consequentemente, o objeto de dados pode ser representado como uma tabela.

Os cabealhos da tabela refletem os atributos do objeto. O corpo da tabela representa

instncias especificas do objeto de dados.
As setas indicadas do uma importante informao sobre a
direo do relacionamento e, normalmente, reduzem a
ambiguidade ou interpretaes incorretas. O par objetorelacionamento bsico no modelo de dados. Usava-se um DER
(diagrama de entidade relacionamento), mas a UML j usada para projeto de dados.
MODELAGEM BASEADA EM CLASSES
A Modelagem Baseado em Classes representa os objetos que o sistema ir manipular, as
operaes (tambm denominadas mtodos ou servios) que sero aplicadas aos objetos
para efetuar a manipulao, os relacionamentos (alguns hierrquicos) entre os objetos e
as colaboraes que ocorrem entre as classes definidas.
Os elementos de um modelo baseado em classes so: classes e objetos, atributos,
operaes, modelos CRC (classe-responsabilidade-colaborador), diagramas de
colaborao e pacotes.
Identificao de classes de anlise
Podemos comear a identificar classes realizando uma "anlise sinttica" dos casos de
uso desenvolvidos. As classes so determinadas sublinhando-se cada substantivo ou
frase contendo substantivos e introduzindo-a em uma tabela simples.

Se for preciso que a classe (substantivo) implemente uma soluo, ento ela faz parte do
espao de solues; caso contrrio, se for necessria uma classe apenas para descrever
uma soluo, ela faz parte do espao de problemas.
"O intuito da orientao a objetos encapsular, mas, ainda, manter separados os dados e
as operaes sobre os dados".
ESPECIFICAO DE ATRIBUTOS
Os atributos descrevem uma classe selecionada para ser includa no modelo de
requisitos e definem uma classe que esclarecem o que a classe representa no contexto
do espao de problemas.
"Quais dados (compostos e/ou elementares) definem completamente esta classe no
contexto do problema em mos?".
Definio das operaes
As operaes definem o comportamento de um objeto.
Quatro grandes categorias:
(l) operaes que manipulam dados de alguma forma (por exemplo, adio, eliminao,
reformatao. seleo).
(2) operaes que realizam um clculo.
(3) operaes que pesquisam o estado de um objeto.
(4) operaes que monitoram um objeto em termos de ocorrncias de um evento de
controle.
Tais funes so realizadas operando-se sobre atributos e/ou associaes {Seo 6.5.5).
Consequentemente, uma operao deve ter "conhecimento" da natureza dos atributos e
associaes das classes.
A anlise sinttica estudada e os verbos so isolados. Alguns dos verbos sero as
operaes legtimas e podem ser facilmente associadas a uma classe especfica.
Pode-se ter uma melhor viso sobre outras operaes considerando-se a comunicao
que ocorre entre os objetos. Os objetos se comunicam passando mensagens entre si.
Modelagem CRC (Classe-Responsabilidade-Colaborador)
A modelagem CRC (classe-responsabilidade-colaborador) fornece uma maneira simples
para identificar e organizar as classes que so relevantes para os requisitos do sistema
ou produto.
Modelagem CRC:

Um conjunto de fichas padro que representam classes. Os cartes so divididos em trs

sees. Ao longo da parte superior do carto escrevemos o nome da classe. No corpo do
carto enumeramos as responsabilidades da classe do lado esquerdo e os colaboradores
do lado direito.
Fichas reais ou virtuais. O intuito desenvolver uma representao organizada das
classes.
As responsabilidades (qualquer coisa que a classe sabe ou faz) so os atributos e as
operaes que so relevantes para a classe.
Diretrizes para alocao de responsabilidades:
1. A inteligncia do sistema deve ser distribuda pelas classes para melhor atender s
necessidades do problema. Porm, se a inteligncia do sistema for distribuda de forma
mais homognea pelas classes de uma aplicao, cada objeto conhecer e far apenas
algumas poucas coisas. A coeso do sistema aumentar, o que aumenta a facilidade de
manuteno do software e reduz efeitos colaterais devido a mudanas.
Uma lista extraordinariamente longa de responsabilidades indica uma concentrao de
inteligncia.
2. Cada responsabilidade deve ser declarada da forma mais genrica possvel. Essa
diretriz implica que as responsabilidades gerais (tanto atributos quanto operaes)
devem estar no topo da hierarquia de classes (por elas serem genricas, sero aplicveis
a todas as subclasses).
3. As informaes e o comportamento relativos a elas devem residir na mesma classe.
Isso atende o princpio da orientao a objetos denominado encapsulamento. Os dados e
os processos que manipulam os dados devem ser empacotados como uma unidade
coesiva.
4. As informaes sobre um item devem estar em uma nica classe e no distribuda por
vrias classes. Uma nica classe deve assumir a responsabilidade pelo armazenamento e
manipulao de um tipo de informao especfico. *lc responsabilidade no deve, em
geral, ser compartilhada por uma srie de classes. Se as informaes forem distribudas,
o software se torna mais difcil de ser mantido e testado.
5. Quando apropriado, as responsabilidades devem ser compartilhadas entre classes
relacionadas. H muitos casos em que uma srie de objetos relacionados deve
apresentar o mesmo comportamento ao mesmo tempo.
Colaboraes
As classes cumprem suas responsabilidades de duas formas: (l) Uma classe pode usar
suas prprias operaes para manipular seus prprios atributos, cumprindo, portanto,
determinada responsabilidade ou (2) uma classe pode colaborar com outras classes.

As colaboraes representam solicitaes de um cliente a um servidor no cumprimento

de uma responsabilidade do cliente. A colaborao a expresso do contrato entre o
cliente e o servidor... Dizemos que um objeto colabora com outro objeto se, para
cumprir uma responsabilidade, ele precisar enviar ao outro objeto quaisquer mensagens.
Uma colaborao simples flui em uma direo representando uma solicitao do cliente
ao servidor. Do ponto de vista do cliente, cada uma de suas colaboraes est associada
a determinada responsabilidade implementada pelo servidor.
As colaboraes so identificadas determinando se uma classe pode ou no cumprir
cada responsabilidade por si s. Caso no possa, ela precisa interagir com outra classe.
Da, a colaborao.
Colaboradores so aquelas classes que so necessrias para fornecer a uma classe as
informaes necessrias para completar uma responsabilidade. Em geral, colaborao
implica uma solicitao de informaes ou uma solicitao de alguma ao.
Consideram-se as seguintes categorias:
Classes de entidades so extradas diretamente do enunciado do problema (persistem
ao longo de toda a existncia da aplicao).
Classes de fronteira so usadas para criar a interface (por exemplo, tela interativa ou
relatrios impressos) que o usurio v e interage medida que o software usado. Os
objetos de entidades contm informaes importantes para os usurios, mas eles no so
exibidos. As classes de fronteira gerenciam a forma atravs da qual os objetos de
entidades so representados para os usurios.
Classes de controle gerenciam a criao ou a atualizao de objetos de entidades, a
instanciao de objetos de fronteira medida que forem obtendo informaes dos
objetos de entidades, a comunicao complexa entre conjuntos de objetos, e a validao
de dados transmitidos entre objetos ou entre o usurio e a aplicao.
Em geral, as classes de controle no so consideradas at que a atividade de projeto
tenha sido iniciada.

Requisitos No Funcionais: so requisitos relacionados ao uso da aplicao em termos

de desempenho, usabilidade, confiabilidade, segurana, disponibilidade,
manuteno e tecnologias envolvidas. No preciso o cliente dizer sobre eles, pois eles
so caractersticas mnimas de um software de qualidade, ficando a cargo de o
desenvolvedor optar por atender esses requisitos ou no. Classificao: Requisitos de
produtos : Requisitos que especificam o comportamento do produto. Ex. portabilidade;
tempo na execuo; confiabilidade, mobilidade, etc. Requisitos da organizao:
Requisitos decorrentes de polticas e procedimentos corporativos. Ex. padres,
infraestrutura, etc. Requisitos externos: Requisitos decorrentes de fatores externos ao
sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade,
legislao, localizao geogrfica etc. Requisitos de facilidade de uso. Ex.: usurios
devero operar o sistema aps um determinado tempo de treinamento. Requisitos de
eficincia. Ex.: o sistema dever processar n requisies por um determinado tempo.
Requisitos de confiabilidade. Ex.: o sistema dever ter alta disponibilidade, exemplo,
99% do tempo. Requisitos de portabilidade. Ex.: o sistema dever rodar em qualquer
plataforma. Requisitos de entrega. Ex.: um relatrio de acompanhamento dever ser
fornecido toda segunda-feira. Requisitos de implementao.: Ex.: o sistema dever ser
desenvolvido na linguagem Java. Requisitos de padres.: Ex. uso de programao
orientada a objeto sob a plataforma A. Requisitos de interoperabilidade: Ex. o sistema
dever se comunicar com o SQL Server. Requisitos ticos. Ex.: o sistema no
apresentar aos usurios quaisquer dados de cunho privativo. Requisitos legais. Ex.: o
sistema dever atender s normas legais, tais como padres, leis, etc. Requisitos de
Integrao. Ex.: o sistema integra com outra aplicao.