UP Universidade Positivo BACHARELADO EM SISTEMAS DE INFORMAO

UML (UNIFIED MODELING LANGUAGE)

CURITIBA 2011

ALAN NUNES CAETANO BRUNA CAROLINA FERREIRA LUAREN RODRIGUES RODRIGO GOMES TEOBALDO

UML (UNIFIED MODELING LANGUAGE)

Trabalho parcial Sistemas

apresentado de de nota II do

como

requisito de em Prof

disciplina Bacharelado da UP Docente:

Programao Universidade

Informao Positivo.

Eduardo Hamerski.

CURITIBA 2011

Sumrio

1.0Introduo............................................................................ .........................5 2.0 O que UML?................................................................... ............................6 3.0 Para que serve?............................................................. ................................6 4.0 Onde a UML usada?............................................ ......................................7 5.0 Qual a relao entre o UML gerado para um projeto e o cdigo produzido? ................................ ................................ ................................ .......... 8 6.0 Quais os principais processos de desenvolvimento que utilizam UML? ....... 9 6.1 Fases do Desenvolvimento de um Sistema em UML ................................ ... 9 6.1.1 Anlise de Requisitos ................................ ................................ ................ 9 6.1.2 Anlise ................................ ................................ ................................ ....... 9 6.1.3 Design (Projeto) ................................ ................................ ....................... 10 6.1.4 Programao ................................ ................................ ........................... 10 6.1.5 Testes ................................ ................................ ................................ ...... 11 7.0 Quais so os tipos de diagrama e para que servem? ................................ . 11 7.1 Modelo Esttico ................................ ................................ .......................... 11 7.1.1 Diagrama de classes ................................ ................................ ............... 11 7.1.1.1 Relacionamentos entre objetos............................................12 7.2 Modelo Dinmico ................................ ................................ ........................ 13 7.2.1 Diagrama de Estado ................................ ................................ ................ 13 7.2.2 Diagrama de Sequncia ................................ ................................ .......... 14 7.2.3 Diagrama de Colaborao ................................ ................................ ..... 155 7.2.4 Diagrama de Atividade ................................ ................................ ............. 15 7.3 Modelo Funcional ................................ ................................ ....................... 15 7.3.1 Diagrama de Componente ................................ ................................ ....... 15 7.3.2 Diagrama de instalao/execuo ................................ ........................... 16 8.0 O que so diagrama de casos de uso? ................................ ...................... 17
3

8.1 O que diagrama de caso de uso? ................................ ............................ 17 8.1.1 Relacionamentos entre casos de uso ................................ ...................... 18 8.1.2 Tipos de casos de uso ................................ ................................ ............. 18 8.1.3 Exemplos de casos de uso: ................................ ................................ ..... 20 8.1.3.1 Exemplo 1 ................................ ................................ ............................. 20 8.1.3.2 Exemplo 2 ................................ ................................ ............................. 20 9.0 Especificao de caso de uso ................................ ................................ .... 21 9.1 Modelo de Especificao de Caso de Uso ................................ ................. 24 6.3. Regra de Aplicao ................................ ................................ ................... 26 6.4. Regra de Negcio ................................ ................................ ...................... 26 7. Informaes Suplementares ................................ ................................ ......... 27 10.0 Concluso ................................ ................................ ................................ . 28 11.0 Referncia Bibliogrfica ................................ ................................ ............ 29 12. Anexos ................................ ................................ ................................ ........ 30 12.1 Figura I. Exemplo de caso de uso I ................................ .......................... 30 12.2 Figura II. Exemplo de caso de uso II................................................. .......30

1.0 Introduo

A UML uma padronizao de modelagem orientada a objetos de forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistncia, fcil de comunicar com outras aplicaes, simples de ser atualizado e compreensvel. Um grande problema no desenvolvimento de novos sistemas utilizando a orientao a objetos o fato de no existir uma notao padronizada e realmente eficaz que possa abra nger qualquer tipo de aplicao. Com o lanamento da UML (UnifiedModelingLanguage) desenvolvedores da rea de orientao a objetos, ficaram entusiasmados com sua abrangncia. Com este trabalho pretendemos justamente pesquisar sobre esta linguagem de modelagem, suas aplicaes, vantagens e desvantagens.

2.0 O que UML?

UML siginica UnifiedModelingLanguage e a padronizao das metodologias de desenvolvimento de sistemas baseados na orientao a objetos. A UML foi criada por trs grandes desenvolvedores de sistemas orientados a objetos: GradyBooch, James Rumbaugh, e Ivar Jacobson, que j haviam criado outras notaes de desenvolvimento de software. A UML incorpora as noes do desenvolvimento de software totalmente visual. Ela se baseia em diagramas que so modelados e classificados em vises de abstrao. O desenvolvimento de um sistema em UML divide-se em 5 fases: anlise de requisitos, anlise, design, implementao (programao) e testes. A UML se prope a ser a linguagem definitiva para modelagem de sistemas orientados a objetos por ser unificada e facilitar que grupos de desenvolvimentos de software interpretem de uma maneira correta e sem ambiguidades modelos gerada por outros analistas ou grupos de desenvolvimento.

3.0 Para que serve?

A UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Os objetivos da UML so: especificao, documentao o, estruturao para sub -visualizao e maior visualizao lgica do desenvolvimento completo de um s istema de informao. A UML um modo de padronizar as formas de modelagem.

4.0 Onde a UML usada?

A UML usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer caracterstica de um sistema em um de seus diagramas e tambm aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificao da anlise de requisitos at a finalizao com a fase de testes. O objetivo da UML descrever qualquer tipo de sistema, em termos de diagramas orientados a o bjetos. Naturalmente, o uso mais comum para criar modelos de sistemas de software, mas a UML tambm usada para representar sistemas mecnicos sem nenhum software. Aqui esto alguns tipos diferentes de sistemas com suas caractersticas mais comuns:
y Sistemas de Informao: Armazenar, pesquisar, editar e mostrar

informaes para os usurios. Manter grandes quantidades de dados com relacionamentos complexos, que so guardados em bancos de dados relacionais ou orientados a objetos.
y Sistemas Tcnicos: Manter e controlar equipamentos tcnicos como de

telecomunicaes, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programao de software de que os sistemas de informao. Sistemas Tcnicos so geralmente sistemas real-time.
y Sistemas Real-time Integrados: Executados em simples peas de

hardware integrados a telefones celulares, carros, alarmes etc. Estes sistemas implementam programao de baixo nvel e requerem suporte real-time.
y Sistemas Distribudos: Distribudos em mquinas onde os dados so

transferidos facilmente de uma mquina para outra. Eles requerem mecanismos de comunicao sincronizados para garantir a integridade dos dados e geralmente so construdos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI.

y Sistemas de Software: Definem uma infra-estrutura tcnica que outros

softwares utilizam. Sistemas Operacionais, bancos de dados, e aes de usurios que executam aes de baixo nvel no hardware, ao mesmo tempo em que disponibilizam interfaces genricas de uso de outros softwares.
y Sistemas de Negcios: descreve os objetivos, especificaes (pessoas,

computadores etc.), as regras (leis, estratgias de negcios etc.), e o atual trabalho desempenhado nos processos do negcio. importante perceber que a maioria dos sistemas no possui apenas uma destas caractersticas acima relacionadas, mas vrias delas ao mesmo tempo. Sistemas de informaes de hoje, por exemplo, podem ter tanto caractersticas distribudas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas.
5.0 Qual a relao entre o UML gerado para um projeto e o cdigo produzido?

Em certas ocasies para desenvolver um projeto, desenvolvedores aplicam muito tempo na atividade de programao, que poderia ser aplicado em outras atividades do projeto. Ento surge a necessidade de pessoas estudarem a gerao automtica de cdigo, com o objetivo de ajudar os programadores de software. Em aplicaes web, uma atividade que necessita de gerao automtica de cdigo o desenvolvimento de interfaces grficas. Os desenvolvedores, levam muito tempo na implementao delas. Ento surge a necessidade de desenvolver ferramentas para esse propsito. Neste contexto , uma ferramenta que ajuda bastante na gerao de interfaces grficas, a UML (UnifiedModelingLanguage).

6.0 Quais os principais processos de desenvolvimento que utilizam UML? 6.1 Fases do Desenvolvimento de um Sistema em UML

Existem cinco fases no desenvolvimento de sistemas de software: anlise de requisitos, anlise, design (projeto), programao e testes. Estas cinco fases no devem ser executadas na ordem descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e desempenho. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML:
6.1.1 Anlise de Requisitos

Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes chamadas "use -cases". Atravs do desenvolvimento de "use-case", as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem in teresse no sistema so modelados entre as funes que eles requerem, funes estas chamadas de "use-cases". Os atores externos e os "use-cases" so modelados com relacionamentos que possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Cada "use-case" modelado descrito atravs de um texto, e este especifica os requerimentos do ator externo que utilizar este "use-case". O diagrama de "use-cases" mostrar o que os atores externos, ou seja, os usurios do futuro sistema devero esper ar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta ser implementada. A anlise de requisitos tambm pode ser desenvolvida baseada em processos de negcios, e no apenas para sistemas de software.
6.1.2 Anlise

A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras classes, e so descritas no Diagrama de Classe. As colaborae s entre classes tambm so mostradas neste diagrama para desenvolver os "use cases" modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero modeladas classes que pertenam ao domnio principal do pr oblema do software, ou seja, classes

tcnicas que gerenciem banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.
6.1.3 Design (Projeto)

Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero adicionadas para prover uma infra estrutura tcnica: a interface do usurio e de perifricos, gerenciamento de banco de dados, comunicao com outros sistemas, dentre outros. As classes do domnio do problema modeladas na fase de anlise so mescladas nessa nova infra-estrutura tcnica tornando possvel alterar tanto o domnio do problema quanto a infra-estrutura. O design resulta no detalhamento das especifica es para a fase de programao do sistema.
6.1.4 Programao

Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a objetos escolhida (a utilizao de linguagens procedurais extremamente no recome ndada). Dependendo da capacidade da linguagem usada, essa converso pode seruma tarefa fcil ou muito complicada. No momento da criao de modelos de anlise e design em UML, melhor evitar traduzi -los mentalmente em cdigo. Nas fases anteriores, os modelos criados so o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema. A programao uma fase separada e distinta onde os modelos criados so convertidos em cdigo.

6.1.5 Testes

Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando as classes e componentes integrados para se
10

confirmar se as classes esto cooperando uma com as outras como especificado nos modelos. Os testes de aceitao observam o sistema como uma "caixa preta" e verificam se o sistema est funcionando como o especificado nos primeiros diagramas de "use- cases". O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente de acordo com as intenes do usurio final.
7.0 Quais so os tipos de diagrama e para que servem?

Diagramas servem para capturar diferentes vises do sistema.Os diagramas utilizados pela UML so compostos de nove tipos: diagrama de use case, de classes, de objeto, de estado, de sequncia, de colaborao, de atividade, de componente e o de instalao/execuo. Todos os sistemas possuem uma estrutura esttica e um comportamento dinmico. A UML suporta modelos estticos (estrutura esttica), dinmicos (comportamento dinmico) e funcionais. O Modelo esttico suportado pelo diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos podem ser de associaes, heran a (generalizao), dependncia ou refinamentos. Os modelos dinmicos so suportados pelos diagramas de estado, sequncia, colaborao e a tividade. E o modelo funcional suportado instalao/execuo pelos diagramas de componente e

7.1 Modelo Esttico

Faz parte do modelo esttico o s diagramas de classes e de objetos:

7.1.1 Diagrama de classes

O diagrama de classes um diagrama que mostra um conjunto de classes, interfaces e colaboraes e seus relacionamentos. Eles so os diagramas encontrados com maior frequncia na modelagem de sistemas orientados a objetos. So usados para modelar a viso esttica do projeto de um sistema. Na maioria dos casos
1.0 Representao de uma classe:

11

ContaBancaria - numero : String - saldo: double - dataAbertura:

VEICULO

Nome da Classe Atributos da classe

+ criar(cpfString):ContaBancaria + bloquear() : void + desbloquear(): void + creditar(valor): void + debitar(valor): boolean

Mtodos da classe

7.1.1.1 Relacionamentos entre objetos

A associao um elemento do diagrama de classes que representa os relacionamentos que acontecem entre os objeto s durante a execuo do sistemaUma associao representada atravs de um segmento de reta ligando as duas classes s quais os objetos que se relacionam pertencem. A quantidade de objetos relacionados tambm pode ser representada na associao. Uma associao em um diagramade classes possui duas multiplicidades, sendo uma em cada extremo do segmento de reta que associa as classes, como denota o exemplo:
Cliente Pedido 1 0..*

O exemplo acima mostra que nessa relao sempre deve haver um cliente, mas no mais de um, que pode possuir zero ou mais pedidos. Na UML, definimos o significado da associao por trs recursos de notao: 1. Nome de associao: posiciona-se sobre o meio da linha de associao. 2. Direo de leitura: representada por um triangulo apontando a direo em que se deve ler a associao.

12

3. Papel: um objeto que participa de uma associao tem um papel especifico nela, que usado quando o nome da associao no fcil de inferir.

Contratante

Contrata

contratado

Organizao

Neste exemplo, a associao deve ser interpretada da seguinte forma: A organizao, que faz o papel de contratante, contrata o indivduo, no papel de contratado.

7.1.2 Diagrama de objetos Um diagrama de objetos pode ser visto como a representao de uma

instancia de um diagrama de classes, assim como um objeto uma instancia de uma classe, sendo o diagrama de objetos tambm esttico, seguindo o diagrama de classes. Um objeto representado como um retngulo com dois compartimentos, onde no de cima se posiciona a identificao do objeto e no de baixo os atributos e seus respectivos estados. O uso do compartimento dos atributos opcional.A identificao do objeto deve ser escrita sublinhada no formato apresentado no exemplo:
nomeObjeto: NomeClasse

A principal diferena atributo1diagrama de objeto e o diagrama de classes entre o = valor1 que uma classe nica e atravs do seu diagrama pode -se ter uma viso completa de todos os seus relacionamentos, com o objeto diferente pois pode haver vrios objetos da mesma classe instanciados e os relacionamentos mapeados so apenas os existentes naquele momento.
7.2 Modelo Dinmico
atributo2 = valor2

Faz parte do modelo dinmico os seguintes diagramas: de estado , sequncia, colaborao e atividade
7.2.1 Diagrama de Estado
13

ndividuo

Modela o comportamento de um objeto individual. Especifica as sequncias de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos
7.2.2 Diagrama de Sequncia

Um diagrama de sequncia classificado como um diagrama de interao. Um diagrama de interao apresenta as mensagens que so emitidasentre os objetos, o que faz tambm o diagrama de sequncia, com a diferena deste focar no tempo das mensagens. No diagrama de sequncia, pode-se encontrar o tempo que as mensagens permanecem na interao, assim como onde essas mensagens nascem e onde acabam. O diagrama de sequncia possui os seguintes elementos: 1. Atores: So representados como no diagrama de casos de uso. 2. Objetos: denotados assim como no diagrama de objetos. 3. Classes: quando uma mensagem enviada a uma classe pode -se tambm representar uma classe no diagrama de sequncia, sendo como um objeto, porm sem o nome sublinhado. 4. Linhas de vida: cada objeto aparece so bre uma linha vertical tracejada, sendo essa a linha de vida que mostra a ordem em que as mensagens chegam e so enviadas pelo objeto. 5. Mensagens: uma mensagem representada neste diagrama por uma flecha horizontal que liga uma linha de vida a outra. A fle cha sempre parte do objeto remetente, que envia a mensagem, e apontapara o objeto receptor, que recebe a mensagem. H tipos diferentes de mensagens, que so representados por tipos diferentes de flechas. Segue os tipos:
Simples Sncrona Assncrona Retorno

14

A boa prtica recomenda que se arranjem os objetos da esquerda para a direita, na ordem em que emitem mensagens, posicionando mais a esquerda os que emitem mensagem primeiro e mais a direita os receptores.
7.2.3 Diagrama de Colaborao

Diagramas de Colaborao mostram as interaes que ocorrem entre os objetos participantes numa situao especfica. Isto mais ou menos a mesma informao mostrada pelos Diagramas de Sequncia, mas neste a nfase colocada em como as interaes ocorrem no tempo, enquanto os Diagramas de Colaborao colocam os relacionamentos entre os objetos e sua topologia em destaque. Em Diagramas de Colaborao as mensagens enviadas de um objeto para outro so representadas por setas, mostrando o nome da mensagem, parmetros, e a sequncia da mensagem. Diagramas de Colaborao so especialmente indicados para mostrar um fluxo ou situao especfica do programa e so um dos melhores tipos de diagrama para rapidame nte demonstrar ou explanar um processo na lgica do programa.
7.2.4 Diagrama de Atividade

usado para mostrar uma sequncia de atividades. Mostra o fluxo de trabalho (workflow) a partir de um ponto inicial at um ponto final, detalhando as decises do caminho tomado durante a execuo das tarefas. Este diagrama possui vrias aplicaes, desde a definio do fluxo bsico de um programa at a definio de um processo com as suas tomadas de decises e aes.
7.3 Modelo Funcional

Faz parte do modelo funcional os seguintes diagramas: de componentes e instalao/execuo:

7.3.1 Diagrama de Componente

O diagrama de componente e o de instalao -execuo so diagramas que mostram o sistema por um lado funcional, expondo as relaes entre seus

15

componentes e a organizao de seus mdulos durante sua execuo. O diagrama de componente descreve os componentes de softwar e e suas dependncias entre si, representando a estrutura do cdigo gerado. Os componentes so a implementao na arquitetura fsica dos conceitos e da funcionalidade definidos na arquitetura lgica (classes, objetos e seus relacionamentos). Eles so tipicamente os arquivos implementados no ambiente de desenvolvimento. Um componente mostrado em UML como um retngulo com uma elipse e dois retngulos menores do seu lado esquerdo. O nome do componente escrito abaixo ou dentro de seu smbolo.Componentes so tipos, mas apenas componentes executveis podem ter instncias. Um diagrama de componente mostra apenas componentes como tipos. Para mostrar instncias de componentes, deve ser usado um diagrama de instalao-execuo, onde as instncias executveis so alocadas em nodes. A dependncia entre componentes pode ser mostrada por uma linha tracejada com uma seta,simbolizando que um componente precisa do outro para possuir uma definio completa. Com o diagrama de componentes facilmente visvel detectar que arquivos dll so necessrios para executar a aplicao. Componentes podem definir interfaces que so visveis para outros componentes. As interfaces podem ser definidas ao nvel da codificao (como em Java) e tambm ao nvel binrio com interfaces binrias usadas em run-time (como em OLE). Uma interface mostrada como uma linha partindo do componentee com um crculo na outra extremidade. O nome colocado junto do crculo no final da linha.Dependncias entre componentes podem ento apontar para a interfa ce do componente que est a ser usada.
7.3.2 Diagrama de instalao/execuo

O diagrama de instalao-execuo mostra a arquitetura fsica do hardware e do software no sistema. Pode mostrar os atuais computadores e perifricos, juntamente com a s conexes que eles estabelecem entre si e pode tambm mostrar os tipos de conexes entre esses computadores e perifricos. Especificam-se tambm os componentes executveis e objetos que so alocados para mostrar quais unidades de software que so executadas e em que computadores so executados. O diagrama de instalao-execuo
16

demonstra

arquitetura

run-time

de

processadores,

componentes

fsicos(devices), e de software que trabalham no ambiente onde o sistema desenvolvido ser utilizado. a ltima descrio fsica da topologia do sistema, descrevendo a estrutura de hardware e software que executa cada unidade. O diagrama de instalao-execuo composto por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos fsicos que fazem partedo sistema, podendo ser uma mquina cliente numa LAN, uma mquin a servidora, uma impressora, um router, etc., e conexes entre estes nodes e componentes que juntos compem toda a arquitetura fsica do sistema.
8.0 O que so diagrama de casos de uso? 8.1 O que diagrama de caso de uso?

O diagrama de casos de uso um diagrama da UML cujo objetivo representar um requisito do sistema que ser automatizado. Tem o objetivo de auxiliar a comunicao entre os analistas e o cliente. Considere como requisito uma necessidade do sistema, ou seja ele descreve um cenrio que mostra as principais funcionalidades do sistema do ponto de vista do cliente.
Notao

O diagrama de Caso de Uso representado por:

y y y

atores; casos de uso; relacionamentos entre estes elementos.

Usamos atores para representar as entidades que interagem com o sistema. Podem ser usurios, mquinas, sensores, etc. Um ator representa um papel no sistema, mas um papel pode ser representando por vrios atores. Estes relacionamentos podem ser:
y y y

associaes entre atores e casos de uso; generalizaes entre os atores; generalizaes, extends e includes entre os casos de uso.
17

Casos de uso podem opcionalmente estar envolvidos por um retngulo que representa os limites do sistema.
Em maiores detalhes:
y

Atores

Um ator representado por um boneco e um rtulo com o nome do ator. Um ator um usurio do sistema, que pode ser um usurio humano ou outro sistema computacional.

Caso de uso

Um caso de uso representado por uma elipse e um rtulo com o nome do caso de uso. Um caso de uso define uma grande funo do sistema. A implicao que uma funo pode ser estruturada em outras funes e, portanto, um caso de uso pode ser estruturado.
8.1.1 Relacionamentos entre casos de uso

Ajudam a descrever casos de uso.

8.1.2 Tipos de casos de uso: Associao: Ocorre entre um ator e um caso de uso. Define uma funcionalidade do sistema do ponto de vista do usurio.

Generalizao: Ocorre entre atores. Os casos de uso de B so tambm

casos de uso de A. E A tem seus prprios casos de uso.

18

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 tambm 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 (no essencial). A extenso inserida em um ponto de extenso do caso de uso A. Ponto de extenso em um caso de uso uma indicao de que outros casos de uso podero ser adicionados a ele. Quando o caso de uso for invocado, ele verificar se suas extenses devem ou no sereminvocadas.Quando se especifica B extends A, a semntica : * Dois casos de uso so definidos: A e A extendedby B; * B uma variao de A. Contm eventos adicionais, para certas condies; * Tem que ser especificado onde B inserido em A.
Generalizao ou Especializao (_um): caso de uso B um caso de uso A

(A uma generalizao de B, ou B uma especializao de A).Ou seja, um relacionamento entre um caso de uso genrico para um mais especfico, que herda todas as caractersticas de seu pai.
19

Sistema Limites do sistema : representado por um retngulo envolvendo os casos de

uso que compem o sistema.

Nome do sistema : Localizado dentro do retngulo. 8.1.3 Exemplos de casos de uso: 8.1.3.1 Exemplo 1

8.1.3.2 Exemplo 2

Exemplo de um diagrama de casos de uso (sistema bancrio):

20

O ator cliente executar os casos de uso realizar saque e consultar saldo, enquanto o gerente poder interagir com os casos de uso abrir conta e vender seguro.
9.0 Especificao de caso de uso

Um caso de uso tem como caractersticas:

y y y y

Descrever o sistema de um ponto de vista externo. Representa um uso especfico do sistema. Indica um padro de comportamento. Deve descrever:

1. Atores e suas interaes. 2. Aes e responsabilidades do sistema. Assim, a Especificao de Caso de Uso um artefato que detalha as caractersticas do caso de uso. Entre outras informaes destacam -se:
1. Nome do Caso de Uso

Recomenda-se: Iniciar com verbo no Infinitivo. Utilizar nome completo, onde as primeiras letras devem ser maisculas, exceto preposies. Este nome deve retratar claramente a ao a ser realizada.
2.Objetivo

Deve oferecer uma ideia geral do propsito do caso de uso. Sua finalidade, a que se destina.

21

3.Tipo de Caso de Uso (opcional)

Podemos classificar um Caso de Uso em Concreto ou Abstrato.

y

Um caso de uso concreto iniciado por um ator e constitui um fluxo completo de eventos. "Completo" significa que a instncia do caso de uso executa o fluxo inteiro invocado pelo ator.

Um caso de uso abstrato nunca instanciado diretamente por um ator. Casos de uso abstratos so includos em (relacionamento de include), estendidos por (relacionamento de extend), ou especializados em (relacionamento de generalizao) outros casos de uso.

Em resumo: caso de uso abstrato no instanciado diretamente por um ator (serve para heranas, por exemplo). Caso de uso concreto pode ser instanciado por um ator.
4. Atores

Relacionar os atores que interagem com o caso de uso, comeando pelo ator que inicia a interao. Recomenda -se: Utilizar nome completo, onde as primeiras letras devem ser maisculas, exceto preposies. Tipos de Atores:
y y

Primrio: caso o ator inicie o caso de uso. Secundrio: caso o ator participe forma passiva (por exemplo, soment e recebe informaes).

5. Pr-condies (opcional)

Texto que identifica as pr -condies do caso de uso. Pr-condies so condies que devem ser satisfeitas para que o caso de uso possa iniciar. Recomenda-se: Na falta de pr-condies para o caso de uso indicar com o texto: "No h pr-condio identificada".

22

Obs.: A Pr-condio uma restrio para o incio do caso de uso, no o evento que inicia o caso de uso.
6. Fluxo Principal

Aqui se descreve o chamado "caminho feliz" (happy path). Escrever o cenrio mais utilizado pelos atores. Este cenrio apresenta o caminho percorrido pelo ator para atingir o objetivo com sucesso. Recomenda -se: A numerao dos passos deve ser seqencial e iniciar em 1. A numerao dos subpassos deve preservar o ndice do passo-pai, acrescido ao nmero identificador do subpasso, iniciando em 1. P(n). (Ttulo do passo) (Descrio do passo) Descrio do passo: texto claro e objetivo indicando a etapa (funo) que o passo descreve. Evitar a fragmentao de passos provocada pela decomposio funcional. Opcional na existncia de subpassos ou na eventualidade do ttulo e descrio serem iguais. P(n.m). Texto resumido indicando a etapa que o subpasso descreve. A criao de subpassos opcional, somente sendo recomendada para passos mais complexos.
7. Fluxos Alternativos (opcional)

Indicar os cenrios alternativos utilizados pelos atores. Recomend a-se: A numerao dos procedimentos deve ser seqencial e iniciar em 1. Os caminhos alternativos devem percorrer um fluxo completo, demonstrando: a. o passo a que esto associados. b. a condio que aciona a entrada no caminho alternativo c. as aes tomadas no caminho alternativo d. a ao de retorno. A(n). descrio do fluxo alternativo.
8. Fluxos de Exceo (opcional)

23

Indicar os cenrios de exceo, isto , onde ocorrem erros. Tais cenrios descrevem os erros previstos que podem ocorrer no uso da aplicao. Recomenda-se: Como nos fluxos alternativos, descrever um fluxo completo, observando o disposto nos itens a, b, c, e d. E(n). descrio do fluxo de exceo.
9. Ps-condies (opcional)

9.1 Modelo de Especificao de Caso de Uso Caso de Uso: Manter Funcionrio 1. Descrio:

Este caso uso tem por objetivo permitir consultar, incluir, alterar e excluir o registro de funcionrios no sistema SISFUNC (Sistema Funcional da ConstruMarte).
2. Ator:

Administrador; Secretaria.
3. Pr-Condio:

- O ator dever estar devidamente cadastrado no sistema com perfil de Administrador ou secretaria. - O funcionrio dever ter entregado toda a documentao solicitada no RH, para ser cadastrado conforme regime CLT.
4. Ps-Condio:

- Cadastro do funcionrio mantido no sistema.

5. Requisitos Associados:

- Gerar Folha de Pagamento.

24

6. Fluxo de Eventos 6.1. Fluxo Principal

P1- O caso de uso iniciado quando o Ator acessa o sistema e seleciona a opo Consultar Funcionrio no menu principal. P2- O sistema apresenta interface de consulta de funcionrios. P3- O ator informa o CPF do funcionrio e seleciona a opo Consultar. (A3), (A4), (RA1). P4- O sistema realiza a busca e apresenta a interface Manter Funcionrio. (A1), (A2). P5- O ator preenche os dados cadastrais do fucionrio e seleciona a opo Incluir. P6- O sistema valida as informaes e solicita a confirmao de incluso. (A3), (A4), (RA2), (RA3), (RA4), (RA5). P7- O ator confirma a incluso selecionando a opo OK. P8- O sistema apresenta a mensagem Operao realizada com sucesso. P9- O caso de uso encerrado.
6.2. Fluxo Alternativo A.1. Alterar Funcionrio.

A.1.1. O ator altera os dados cadastrais desejados e seleciona a opo Alterar. A.1.2. O sistema valida as informaes e solicita a confirmao da alterao. (A3), (A4), (RA2), (RA3), (RA4), (RA5), (RN1). A.1.3. O ator confirma a alterao selecionando a opo OK. (P8)
A.2. Excluir Funcionrio.

A.2.1. O ator seleciona a opo Excluir. A.2.2. O sistema valida o Perfil e solicita a confirmao da excluso. (A5), (RN2), (RN3), (RN4). A.2.3. O ator confirma a excluso selecionando a opo OK. (P8)
A.3. Validar dados

A.3.1. O sistema apresenta a mensagem: Dado(s) invlido(s). Favor Verificar!

25

(P5), (A1.1).
A.4. Preencher campo Obr igatrio

A.4.1. O sistema apresenta a mensagem: Campo obrigatrio no preenchido, Favor Verificar! (P5), (A1.1).
A.5. Validar Perfil

A.5.1. O sistema apresenta a mensagem: Voc no possui perfil para realizar esta transao, Por favor, realize o login com o perfil de administrador! (P2).
A.6. Cancelar

A.5.1. O sistema retorna ao passo (P2).

6.3. Regra de Aplicao

RA1. O campo CPF dever ser composto de 11(onze) dgitos numricos no formato (99999999999). RA2. O campo data de nascimento composto de 08(oito) dgitos numricos no formato a seguir (DD/MM/AAAA). RA3. O campo endereo composto de 50(cinqenta) caracteres alfanumricos. RA4. O campo telefone composto de 10(Dez) dgitos numricos no formato a seguir (99) 99999999. RA5. O campo CEP composto de 08(oito) dgitos numricos no formato a seguir (99999999).
6.4. Regra de Negcio

RN1. A alterao do cadastro do funcionrio apenas ser permitida 30 dias aps a sua incluso. RN2. O funcionrio apenas poder ser inativado por funcionrio com pe rfil de Administrador. RN3. O cadastro apenas poder ser excludo 30 dias aps o encerramento do aviso prvio, conforme data de demisso informado na CTPS. RN4. A excluso do registro do funcionrio dever ocorrer apenas de forma
26

lgica.
7. Informaes Suplementares

- CLT: Consolidao das Leis do Trabalho. - CTPS: Carteira de Trabalho e Previdncia Social

27

10.0 Concluso

Considera-se que o objetivo principal do trabalho, mostrar qual o papel e aimportncia da linguagem UML, foi atingida .Isto se deve ao fato de que o as regras estudadas, possibilitam, uma melhor escrita e entendimentodos cdigos gerados.Em virtude das constantes inovaes que surgem em ferramentasde desenvolvimento de sistemas orientadas a o bjetos, podemos afirmar aimportncia do uso da modelagem UML em todas as fases doprocesso, desde os eventos iniciais, passando pela anlise de requisitos,anlise, projeto, implementao e testes. Partindo deste principio conclui se que foi apresentada um a metodologia de desenvolvimento de sistemas orientados a objetos baseada em UML(UnifiedModelingLanguage), a partir da qual o desenvolvedor poder seguir suas etapas para o fluxo correto do desenvolvimento de um projeto. Portanto, a partir dos estudos realizados, pde-se concluir que preciso adotar as a metodologia de desenvolvimento UML, a fim de ter um melhor desempenho no decorrer do projeto.

28

11.0 Referncia Bibliogrfica

Disponvel em: <http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SI II/Uml/diagramas/usecases/usecases.htm>Acesso em: 19 de maro de 2011 Disponvel em:<http://celodemelo.wordpress.com/2007/03/17/entendedo -odiagrama-de-casos-de-uso/> Acesso em: 19 de maro de 2011 Disponvel em: <http://www.macoratti.net/net_uml1.htm> Acesso em: 19 de maro de 2011 Disponvel em: <http://www.wthreex.com/rup/webtmpl/templates/req/rup_ucspec.htm>Acesso em: 19 de maro de 2011 Disponvel em: <http://pt.scribd.com/doc/6335180/Especificacao -de-Caso-de-Uso-FazerReserva-de-Veiculo>Acesso em: 19 de maro de 2011 Livros: * UML guia do usurio : o mais avanado tutorial sobre UnifiedModelingLanguage (UML), GradyBoock, James Rumbaugh, Ivar Jacobson ; traduo Fbio Freitas da Silva e Cristina de Amorim Machado ; reviso tcnica Jussara Pimenta Matos. Edio 2. ed. rev. e atual. Rio de Janeiro : Campus : Elsevier, c2006. * UML L324m Utilizando UML e padres : uma introduo anlise e ao projeto orientados a objetos e ao desenvolvimento iterativo / Craig Larman ; traduo Rosana T. Vaccare Braga ... [et al.] Edio 3. ed. Porto Alegre : Bookman, 2007. * UML M543p Princpios de anlise e projeto de sistemas com UML / Eduardo Bezerra. Rio de Janeiro : Campus, 200
29

12. Anexos Figura I. Exemplo de caso de uso I

Figura II. Exemplo de caso de uso II

30

31