Universidade do Estado do Rio Grande do Norte Disciplina: Anlise e Projeto de Sistemas Professora: Clarissa Arajo Azevedo

Relembrando
Um sistema de informaes uma combinao de pessoas, dados, processos, interfaces, redes de comunicao e tecnologia que interagem para dar suporte e melhorar o processo de negcio de uma organizao empresarial com relao s informaes que nela fluem. Sistemas de software

Complexidade Modelos

Modelos

Gerenciamento da complexidade Comunicao entre as pessoas envolvidas Reduo dos custos no desenvolvimento Predio do comportamento futuro do sistema Como so os modelos de software?
Diagramas
Elementos textuais

O paradigma da orientao a objetos

Princpios (Alan Kay)

Qualquer coisa um objeto. Objetos realizam tarefas da requisio de servios a

outros objetos. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares. A classe o repositrio para comportamento associado ao objeto. Classes so organizadas em hierarquias.

Paradigma estruturado: dados e processos. Anlise orientada a objetos

Diminui a diferena semntica entre a realidade

sendo modelada e os modelos construdos.

Principais conceitos

Classes e objetos Mensagens Princpio da abstrao

Encapsulamento uma forma de restringir o acesso ao comportamento interno de um objeto.
Interface

- Define os servios que um objeto pode realizar e as mensagens que ele recebe.

Polimorfismo Indica a capacidade de abstrair vrias implementaes diferentes em uma nica interface. Herana Classes semelhantes so agrupadas em hierarquia

Histrico

Dcada de 80 -> Anlise Estruturada

Edward Yourdon, Peter Coad, Tom

DeMarco, James Martin e Chris Gane.

Dcada de 90 -> Anlise Orientada a Objetos

Sally Shlaer, Stephen Mellor, Rebecca

Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar Jacobson Padres de projeto, frameworks, componentes, qualidade e UML (1996).

Linguagem de Modelagem Unificada

Grady Booch, James Rumbaugh e Ivar Jacobson Unio de diversas notaes preexistentes. Em 97, foi aceita como padro pela OMG. uma linguagem visual.
Cada elemento grfico possui:
Sintaxe: forma predeterminada de desenhar Semntica: define o significado do elemento e pra que ele

deve ser usado. Extensveis

Permite que a UML seja adaptada s caractersticas especficas

de cada projeto de desenvolvimento.

independente de linguagem de programao e de processo de desenvolvimento. Especificao da UML: www.omg.org

Vises

Os autores da UML sugerem que um sistema pode ser descrito a partir de cinco perspectivas independentes:
Viso de Casos de Uso Descreve o sistema de um ponto de vista externo como um conjunto de interaes entre o sistema e os agentes externos ao sistema. criada inicialmente e direciona o desenvolvimento das outras vises. Viso de Projeto Enfatiza as caractersticas do sistema que do suporte, tanto estrutural quanto comportamental, s funcionalidades externamente visveis do sistema. Viso de Implementao Abrange o gerenciamento de verses do sistema, construdas atravs do agrupamento de mdulos (componentes) e subsistemas. Viso de Implantao Corresponde distribuio fsica do sistema em seus subsistemas e conexo entre essas partes. Viso de Processo Enfatiza as caractersticas de concorrncia (paralelismo), sincronizao e desempenho do sistema.

Diagramas UML

Mecanismos Gerais

A UML composta por trs grandes componentes:

Blocos de construo bsicos Regras que restringem como os blocos de

construo podem ser associados Mecanismos gerais

So usados na maioria dos diagramas UML

Esteretipos
Usado para estender o significado de um determinado elemento em um diagrama. Esteretipos predefinidos Esteretipos definidos pela equipe de desenvolvimento Podem ser classificados como:

Esteretipos grficos (ou de cone) Esteretipos de rtulo

Esteretipo grfico

representado por um cone que lembre o significado do conceito ao qual ele est associado.

Esteretipo de rtulo
representado por um nome delimitado por << e >>, e posicionado prximo ao smbolo. Esteretipos de rtulo predefinidos:

<<documento>> <<interface>>

<<controle>>
<<entidade>>

Notas explicativas
So utilizadas para definir informao que comenta ou esclarece alguma parte de um diagrama. Podem ser descritas em texto livre. Ou como expresso formal utilizando a linguagem de restrio de objetos da UML.

Notas explicativas

Ao contrrio dos esteretipos, as notas textuais no modificam nem estendem o significado do elemento ao qual esto associadas. Elas servem somente para explicar algum elemento do modelo sem modificar sua estrutura ou semntica.

Notas Explicativas

Cuidados:
Notas textuais em excesso podem

carregar visualmente os modelos. Com a evoluo dos modelos, pode ocorrer uma sobrecarga de atualizao das notas que podem deixar de fazer sentido.

Portanto:
Utilizar notas explicativas quando for

realmente necessrio.

Etiquetas (tags)
Pode-se definir outras propriedades, alm das predefinidas, para determinados elementos de um diagrama atravs de etiquetas. Definio: { tag = valor } { tag1 = valor1, tag2 = valor2 ... } { tag }

Etiquetas (tags)

Restries

Permitem estender ou alterar a semntica natural de um elemento grfico. A UML define uma linguagem formal que pode ser utilizada para especificar restries sobre diversos elementos de um modelo.
OCL Object Constraint Language Linguagem de Restrio de Objeto
Utilizada para definir expresses de navegao entre objetos

, expresses lgicas, consultas, etc

Restries tambm podem ser especificadas em

texto livre.

Devem ser delimitadas por chaves { } Devem aparecer dentro de notas explicativas.

Diagrama de Casos de Uso

Idealizada pelo engenheiro de software sueco Iva Jacobson, na dcada de 70 uma representao das funcionalidades externamente observveis do sistema e dos elementos externos ao sistema que interagem com ele. parte integrante da especificao de requisitos
Molda os requisitos funcionais do sistema

Possui notao grfica simples e descrio em linguagem natural

Facilita a comunicao entre desenvolvedores e usurios

Fora os desenvolvedores a moldarem o sistema de acordo com o usurio, e no o usurio de acordo com o sistema.

Casos de Uso
Um caso de uso representa quem faz o qu com o sistema, sem considerar o comportamento interno do sistema. UML no define o formato, o grau de abstrao e o de detalhamento na descrio de um caso de uso.

Formato
Exemplo: Realizar Saque Descrio Contnua

O Cliente chega ao caixa eletrnico e

insere seu carto. O Sistema pede a senha do Cliente. Aps o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opes de operaes possveis. O Cliente opta por realizar um saque. Ento o Sistema requisita o total a ser sacado. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente.

Formato

Descrio Numerada
1. 2. 3. 4. 5.

6.
7.

Cliente insere seu carto no caixa eletrnico. Sistema apresenta solicitao de senha. Cliente digita senha. Sistema exibe menu de operaes disponveis. Cliente indica que deseja realizar um saque. Sistema requisita quantia a ser sacada. Cliente retira a quantia e o recibo.

Formato

Descrio particionada
Sistema
Apresenta solicitao de senha

Cliente
Insere seu carto no caixa eletrnico Digita senha

Exibe o menu de operaes disponveis Solicita realizao de saque Requisita a quantia a ser sacada Retira a quantia e o recibo

Detalhamento

Sucinto
Descreve as interaes sem muitos

detalhes.

Expandido
Descreve as interaes em detalhes.

Grau de abstrao

Diz respeito meno tecnologia a ser utilizada na descrio do caso de uso.

Caso de uso essencial abstrato e no faz meno tecnologia a ser utilizada. Caso de uso real As descries das interaes citam detalhes da tecnologia a ser utilizada para implementar o caso de uso. Regra prtica dos 100 anos

Caso de uso essencial

Cliente fornece sua identificao 2. Sistema identifica o usurio 3. Sistema fornece operaes disponveis 4. Cliente solicita o saque de uma determinada quantia 5. Sistema fornece a quantia desejada da conta do Cliente 6. Cliente recebe dinheiro e recibo.
1.

Caso de uso real

1. Cliente insere seu carto no caixa 2. 3. 4. 5. 6. 7.

eletrnico. Sistema apresenta solicitao de senha. Cliente digita senha. Sistema exibe menu de operaes disponveis. Cliente indica que deseja realizar um saque. Sistema requisita quantia a ser sacada. Cliente retira a quantia e o recibo.

Cenrios

Um cenrio uma execuo especfica de um caso de uso; pode ser visto como uma instncia de um caso de uso. Exemplo: Realizar pedido
Um Cliente telefona para a empresa. Um Vendedor atende ao telefone. Cliente declara seu desejo de fazer um pedido de

compra. Vendedor pergunta a forma de pagamento. Cliente indica que vai pagar com carto de crdito. Vendedor requisita o nmero do carto, a data de expirao e o endereo de entrega. Vendedor pede as informaes do primeiro item. Cliente fornece o primeiro item.

Cenrios

Vendedor pede as informaes do segundo item. Cliente fornece o segundo item. Vendedor pede as informaes do terceiro item. Cliente fornece o terceiro item. Vendedor informa que o terceiro item est fora de estoque. Cliente pede que o Vendedor feche o pedido somente com os dois primeiros itens. Vendedor fornece o valor total, a data de entrega, e uma identificao do pedido. Cliente agradece e desliga o telefone. Vendedor contata a Transportadora para enviar o pedido do Cliente.

Atores

Qualquer elemento externo que interage com o sistema denominado de ator.

Pessoas Empregado, Cliente, Gerente, Vendedor. Organizaes Fornecedor, Agncia de Impostos, Administradora de Cartes Outros sistemas Sistema de Cobrana, Sistema de Estoque Equipamentos Leitora de Cdigo de Barras, Sensor

Um ator pode desempenhar diversos papis.

Atores

O nome do ator deve lembrar o papel e no quem ele representa. Ex:

Cliente, Estudante Joo, Maria

Atores primrios
Iniciam uma seqncia de interaes de um caso de

uso. So os agentes externos que recebem benefcio direto com a aplicao do caso de uso

Atores secundrios
Supervisionam, operam, mantm ou auxiliam na

utilizao do sistema.

Relacionamentos
Um ator deve estar relacionado a um ou mais casos de uso. Os casos de uso podem se relacionar. Tipos:

Comunicao Incluso

Extenso
Generalizao

Relacionamento de Comunicao
Quais atores esto relacionados a que casos de uso. Um ator pode se relacionar com mais de um caso de uso do sistema. o mais comumente usado de todos os relacionamentos.

Relacionamento de Incluso
Existe somente entre casos de uso. Analogia -> rotinas em linguagens de programao. Quando dois ou mais casos de uso incluem uma seqncia comum de interaes, essa seqncia comum pode ser descrita em um outro caso de uso. A partir da, os casos de uso do sistema podem usar esse caso de uso comum.

Relacionamento de Incluso

Exemplo:
Sistema de Controle de Transaes

Bancrias
Obter Extrato Realizar Saque Realizar Transferncia
Fornecer Identificao

Relacionamento de Extenso

Considere dois casos de uso, A e B B estende A A -> estendido B -> extensor utilizado para modelar situaes em que diferentes seqncias de interaes podem ser inseridas (opcionalmente) em um caso de uso (estendido).
Comportamento s ocorre sob certas

condies. Ou sua realizao depende da escolha de um ator.

Relacionamento de Extenso

O caso de uso estendido uma descrio completa de uma seqncia de interaes.

O que no significa que o caso de uso extensor seja utilizado.

Formas alternativas para definir em que ponto no caso de uso estendido pode ocorrer o comportamento do extensor:
Definida na prpria descrio textual do extensor. Vantagem: caso de uso estendido no precisa ser modificado se um extensor for adicionado Desvantagem: se o formato de descrio numerada for usado, o extensor pode referenciar uma numerao desatualizada. Pontos de extenso Vantagem: se o caso de uso estendido tiver sua seqncia atualizada, o extensor no precisa ser modificado. Desvantagem: os pontos de extenso exibidos nos casos de uso estendidos diminuem a clareza e a facilidade de leitura. recomendada a primeira alternativa. Por qu? Poluio da leitura com coisas que sero na maioria das vezes desnecessrias. O extensor pode ser ativado a cada dois passos do estendido.

Relacionamento de Extenso

Exemplo:
Editar Documento Ator abre documento; Modifica-o; Salva; Fecha. Corrigir Ortografia Substituir Texto (copiar/colar)

Relacionamento de Generalizao

Pode existir entre dois casos de uso ou entre dois atores. Permite que um caso de uso (ou um ator) herde caractersticas de um caso de uso (ou ator) mais genrico. Generalizao de casos de uso
Quando B herda de A, as seqncias de comportamento

de A valem tambm para B. B pode redefinir as seqncias de A B participa em qualquer relacionamento de A.

Generalizao entre atores

O ator herdeiro possui o mesmo comportamento (em

relao ao sistema) que o ator do qual ele herda. O ator herdeiro pode participar em casos de uso em que o ator do qual ele herda no participa.

Observaes
Os relacionamentos de extenso, incluso e generalizao ajudam a diminuir a replicao de casos de uso e evita a criao de casos de uso gigantes. No to recomendado usar relacionamentos em excesso para no ficar difcil de ser entendido.

Possibilidades de relacionamentos entre os elementos do modelo de casos de uso

Erros comuns

Considerar o modelos de casos de uso equivalente ao modelo funcional da anlise estruturada (onde se utiliza o DFD).
O modelo de casos de uso representa os possveis usos do

sistema que podem ser associados a um ou mais requisitos do sistema. O DFD tem o objetivo de representar as funes do sistema de uma forma hierrquica para representar como as informaes fluem pelo sistema.

Quebrar em dois ou mais casos de uso funcionalidades que na verdade pertencem a um mesmo caso de uso.
Por exemplo: Imprimir Recibo no um caso de uso em si, e

sim, uma subseqncia dentro do caso Comprar Produto.

Enfoque para utilizao de casos de uso -> identificar os objetivos do usurio, no as funes do sistema.

Diagrama de Casos de Uso

Representa viso externa do sistema. Representa graficamente os atores, casos de uso e relacionamentos entre esses elementos. Atores -> bonecos + nome do ator Caso de uso -> elipse + nome do caso de uso Relacionamento de comunicao -> segmento de reta ligando ator e caso de uso.

Exemplo

Fronteira do Sistema

Enfatiza a diviso entre o interior e o exterior do sistema.

Relacionamento de Incluso

Relacionamento de Extenso

Relacionamento de Herana

Elementos Grficos - DCU

Identificando atores
Que rgos, empresas ou pessoas utilizaro o sistema? 2. Que outros sistemas iro se comunicar com o sistema a ser construdo? 3. Algum deve ser informado de alguma ocorrncia do sistema? 4. Quem est interessado em um certo requisito funcional do sistema?
1.

Identificando casos de uso

Quais so as necessidades e objetivos de cada ator em relao ao sistema? 2. Que informaes o sistema deve produzir? 3. O sistema deve realizar alguma ao que ocorre regularmente no tempo? 4. Para cada requisito funcional, existe um (ou mais) caso(s) de uso para atend-lo?
1.

Exemplo

Exerccio

Construa o driagrama de casos de uso para a seguinte situao fictcia: Estamos criando um servio de entregas. Nossos clientes podem requisitar a entrega de volumes. Alguns volumes so considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor.
Valendo 1,0 ponto na segunda nota.