8QLYHUVLGDGH GR 6XO GH 6DQWD &DWDULQD
&HQWUR GH &Lr QF LDV $ J Ui ULDV ( [ DWDV H GDV ( QJ HQK DULDV 0 RGHODJ HP GH 3 URF HVVRV
N
N
O
O
T
T
A
A
S
S
D
D
E
E
A
A
U
U
L
L
A
A
3
3
Prof
o. Ricardo Villarroel Dávalos, Dr. Eng.
3
Introdução à Linguagem Unificada de Modelagem - UML
3.1 Introdução
O grande problema do desenvolvimento de novos sistemas utilizando a orientação a objetos nas fases de análise de requisitos, análise de sistemas e design é que não existe uma notação padronizada e realmente eficaz que abranja qualquer tipo de aplicação que se deseje. Cada simbologia existente possui seus próprios conceitos, gráficos e terminologias, resultando numa grande confusão, especialmente para aqueles que querem utilizar a orientação a objetos não só sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajudá-los a construir e manter sistemas cada vez mais eficazes.
Quando a "Unified Modeling Language" (UML) foi lançada, muitos desenvolvedores da área da orientação a objetos ficaram entusiasmados já que essa padronização proposta pela UML era o tipo de força que eles sempre esperaram.
A UML é muito mais que a padronização de uma notação. É também o desenvolvimento de novos conceitos não normalmente usados. Por isso e muitas outras razões, o bom entendimento da UML não é apenas aprender a simbologia e o seu significado, mas também significa aprender a modelar orientado a objetos no estado da arte.
UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são conhecidos como "os três amigos". Eles possuem uma extenso conhecimento na área de modelagem orientado a objetos já que as três mais conceituadas metodologias de modelagem orientado a objetos foram eles que desenvolveram e a UML é a junção do que havia de melhor nestas três metodologias adicionado novos conceitos e visões da linguagem. Veremos características de cada uma destas metodologias no desenvolver deste trabalho.
Veremos como a UML aborda o caráter estático e dinâmico do sistema a ser analisado levando em consideração, já no período de modelagem, todas as futuras características do sistema em relação a utilização de "packages" próprios da linguagem a ser utilizada, utilização do banco de dados bem como as diversas especificações do sistema a ser desenvolvido de acordo com as métricas finais do sistema.
3.2 Uso da UML
A UML é usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer característica de um sistema em um de seus diagramas e é também aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de requisitos até a finalização com a fase de testes.
O objetivo da UML é descrever qualquer tipo de sistema, em termos de diagramas orientado a objetos. Naturalmente, o uso mais comum é para criar modelos de sistemas de software, mas a UML também é usada para representar sistemas mecânicos sem nenhum software. Aqui estão alguns tipos diferentes de sistemas com suas características mais comuns:
Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações para os usuários. Manter grandes quantidades de dados com relacionamentos complexos, que são guardados em bancos de dados relacionais ou orientados a objetos.
Sistemas Técnicos: Manter e controlar equipamentos técnicos como de telecomunicações, equipamentos militares ou processos industriais. Eles devem possuir interfaces especiais do equipamento e menos programação de software de que os sistemas de informação. Sistemas Técnicos são geralmente sistemas real-time.
Sistemas Real-time Integrados: Executados em simples peças de hardware integrados a telefones celulares, carros, alarmes etc. Estes sistemas implementam programação de baixo nível e requerem suporte real-time.
Sistemas Distribuídos: Distribuídos em máquinas onde os dados são transferidos facilmente de uma máquina para outra. Eles requerem mecanismos de comunicação sincronizados para garantir a integridade dos dados e geralmente são construídos em mecanismos de objetos como CORBA, COM/DCOM ou Java Beans/RMI.
Sistemas de Software: Definem uma infra-estrutura técnica que outros softwares utilizam. Sistemas Operacionais, bancos de dados, e ações de usuários que executam ações de baixo nível no hardware, ao mesmo tempo que disponibilizam interfaces genéricas de uso de outros softwares.
Sistemas de Negócios: descreve os objetivos, especificações (pessoas, computadores etc.), as regras (leis, estratégias de negócios etc.), e o atual trabalho desempenhado nos processos do negócio.
É importante perceber que a maioria dos sistemas não possuem apenas uma destas características acima relacionadas, mas várias delas ao mesmo tempo. Sistemas de informações de hoje, por exemplo, podem ter tanto características distribuídas como real-time. E a UML suporta modelagens de todos estes tipos de sistemas.
3.3 Fases do Desenvolvimento de um Sistema em UML
Existem cinco fases no desenvolvimento de sistemas de software: análise de requisitos, análise, design (projeto), programação e testes. Estas cinco fases não 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 performance. A seguir falaremos sobre cada fase do desenvolvimento de um sistema em UML:
Análise de Requisitos
Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através do uso de funções chamadas "use-cases". Através do desenvolvimento de "use-case", as entidades externas ao sistema (em UML chamados de "atores externos") que interagem e possuem interesse no sistema são modelados entre as funções que eles requerem, funções estas chamadas de "use-cases". Os atores externos e os "use-cases" são modelados com relacionamentos que possuem comunicação associativa entre eles ou são desmembrados em hierarquia. Cada "use-case" modelado é descrito através 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 usuários do futuro sistema deverão esperar do aplicativo, conhecendo toda sua funcionalidade sem importar como esta será implementada. A análise de requisitos também pode ser desenvolvida baseada em processos de negócios, e não apenas para sistemas de software.
Análise
A fase de análise está preocupada com as primeiras abstrações (classes e objetos) e mecanismos que estarão presentes no domínio do problema. As classes são modeladas e ligadas
através de relacionamentos com outras classes, e são descritas no Diagrama de Classe. As colaborações entre classes também são mostradas neste diagrama para desenvolver os "use-cases" modelados anteriormente, estas colaborações são criadas através de modelos dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros não estarão presentes neste diagrama.
Design (Projeto)
Na fase de design, o resultado da análise é expandido em soluções técnicas. Novas classes serão adicionadas para prover uma infra-estrutura técnica: a interface do usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros sistemas, dentre outros. As classes do domínio do problema modeladas na fase de análise são mescladas nessa nova infra-estrutura técnica tornando possível alterar tanto o domínio do problema quanto a infra-estrutura. O design resulta no detalhamento das especificações para a fase de programação do sistema.
Programação
Na fase de programação, as classes provenientes do design são convertidas para o código da linguagem orientada a objetos escolhida (a utilização de linguagens procedurais é extremamente não recomendada). Dependendo da capacidade da linguagem usada, essa conversão pode ser uma tarefa fácil ou muito complicada. No momento da criação de modelos de análise e design em UML, é melhor evitar traduzi-los mentalmente em código. Nas fases anteriores, os modelos criados são o significado do entendimento e da estrutura do sistema, então, no momento da geração do código onde o analista conclua antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do sistema. A programação é uma fase separada e distinta onde os modelos criados são convertidos em código.
Testes
Um sistema normalmente é rodado em testes de unidade, integração, e aceitação. Os testes de unidade são para classes individuais ou grupos de classes e são geralmente testados pelo programador. Os testes de integração são aplicados já usando as classes e componentes integrados para se confirmar se as classes estão cooperando uma com as outras como especificado nos modelos. Os testes de aceitação 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 usuário final e verificará se os resultados mostrados estão realmente de acordo com as intenções do usuário final.
3.4 A Notação da Linguagem de Modelagem Unificada – UML
Tendo em mente as cinco fases do desenvolvimento de softwares, as fases de análise de requisitos, análise e design utilizam-se em seu desenvolvimento cinco tipos de visões, nove tipos de diagramas e vários modelos de elementos que serão utilizados na criação dos diagramas e mecanismos gerais que todos em conjunto especificam e exemplificam a definição do sistema, tanto a definição no que diz respeito à funcionalidade estática e dinâmica do desenvolvimento de um sistema.
Antes de abordarmos cada um destes componentes separadamente, definiremos as partes que compõem a UML:
Visões: As Visões mostram diferentes aspectos do sistema que está sendo modelado. A visão não é um gráfico, mas uma abstração consistindo em uma série de diagramas. Definindo um número de visões, cada uma mostrará aspectos particulares do sistema, dando
enfoque a ângulos e níveis de abstrações diferentes e uma figura completa do sistema poderá ser construída. As visões também podem servir de ligação entre a linguagem de modelagem e o método/processo de desenvolvimento escolhido.
Modelos de Elementos: Os conceitos usados nos diagramas são modelos de elementos que representam definições comuns da orientação a objetos como as classes, objetos, mensagem, relacionamentos entre classes incluindo associações, dependências e heranças.
Mecanismos Gerais: Os mecanismos gerais provém comentários suplementares, informações, ou semântica sobre os elementos que compõem os modelos; eles provém também mecanismos de extensão para adaptar ou estender a UML para um método/processo, organização ou usuário específico.
Diagramas: Os diagramas são os gráficos que descrevem o conteúdo em uma visão. UML possui nove tipo de diagramas que são usados em combinação para prover todas as visões do sistema.
3.5 Visões
O desenvolvimento de um sistema complexo não é uma tarefa fácil. O ideal seria que o sistema inteiro pudesse ser descrito em um único gráfico e que este representasse por completo as reais intenções do sistema sem ambiguidades, sendo facilmente interpretável. Infelizmente, isso é impossível. Um único gráfico é incapaz de capturar todas as informações necessárias para descrever um sistema.
Um sistema é composto por diversos aspectos: funcional (que é sua estrutura estática e suas interações dinâmicas), não funcional (requisitos de tempo, confiabilidade, desenvolvimento, etc.) e aspectos organizacionais (organização do trabalho, mapeamento dos módulos de código, etc.). Então o sistema é descrito em um certo número de visões, cada uma representando uma projeção da descrição completa e mostrando aspectos particulares do sistema.
Cada visão é descrita por um número de diagramas que contém informações que dão ênfase aos aspectos particulares do sistema. Existe em alguns casos uma certa sobreposição entre os diagramas o que significa que um deste pode fazer parte de mais de uma visão. Os diagramas que compõem as visões contém os modelos de elementos do sistema. As visões que compõem um sistema são:
Visão "use-case": Descreve a funcionalidade do sistema desempenhada pelos atores externos do sistema (usuários). A visão use-case é central, já que seu conteúdo é base do desenvolvimento das outras visões do sistema. Essa visão é montada sobre os diagramas de use-case e eventualmente diagramas de atividade.
Visão Lógica: Descreve como a funcionalidade do sistema será implementada. É feita principalmente pelos analistas e desenvolvedores. Em contraste com a visão use-case, a visão lógica observa e estuda o sistema internamente. Ela descreve e especifica a estrutura estática do sistema (classes, objetos, e relacionamentos) e as colaborações dinâmicas quando
os objetos enviarem mensagens uns para os outros para realizarem as funções do sistema. Propriedades como persistência e concorrência são definidas nesta fase, bem como as interfaces e as estruturas de classes. A estrutura estática é descrita pelos diagramas de classes e objetos. O modelamento dinâmico é descrito pelos diagramas de estado, sequencia, colaboração e atividade.
Visão de Componentes: É uma descrição da implementação dos módulos e suas dependências. É principalmente executado por desenvolvedores, e consiste nos componentes dos diagramas.
Visão de concorrência: Trata a divisão do sistema em processos e processadores. Este aspecto, que é uma propriedade não funcional do sistema, permite uma melhor utilização do ambiente onde o sistema se encontrará, se o mesmo possui execuções paralelas, e se existe dentro do sistema um gerenciamento de eventos assíncronos. Uma vez dividido o sistema em linhas de execução de processos concorrentes (threads), esta visão de concorrência deverá mostrar como se dá a comunicação e a concorrência destas threads. A visão de concorrência é suportada pelos diagramas dinâmicos, que são os diagramas de estado, sequencia, colaboração e atividade, e pelos diagramas de implementação, que são os diagramas de componente e execução.
Visão de Organização: Finalmente, a visão de organização mostra a organização física do sistema, os computadores, os periféricos e como eles se conectam entre si. Esta visão será executada pelos desenvolvedores, integradores e testadores, e será representada pelo diagrama de execução.
3.6 Diagramas
Os diagramas utilizados pela UML são compostos de nove tipos: diagrama de use case, de classes, de objeto, de estado, de sequência, de colaboração, de atividade, de componente e o de execução.
Todos os sistemas possuem uma estrutura estática e um comportamento dinâmico. A UML suporta modelos estáticos (estrutura estática), dinâmicos (comportamento dinâmico) e funcional. A Modelagem estática é suportada pelo diagrama de classes e de objetos, que consiste nas classes e seus relacionamentos. Os relacionamentos podem ser de associações, herança (generalização), dependência ou refinamentos. Os modelamentos dinâmicos são suportados pelos diagramas de estado, sequência, colaboração e atividade. E o modelamento funcional é suportado pelos diagramas de componente e execução.
3.7 Modelos de Elementos
Os conceitos usados nos diagramas são chamados de modelos de elementos. Um modelo de elemento é definido com a semântica, a definição formal do elemento com o exato significado do que ele representa sem definições duvidosas ou ambíguas e também define sua representação gráfica que é mostrada nos diagramas da UML. Um elemento pode existir em diversos tipos de diagramas, mas existem regras que definem que elementos podem ser mostrados em que tipos de diagramas. Alguns exemplos de modelos de elementos são as classes, objetos, estados, pacotes e componentes. Os relacionamentos também são modelos de elementos, e são usados para conectar outros modelos de elementos entre si. Todos os modelos de elementos serão definidos e exemplificados a seguir.
3.8
Ferramenta Enterprise Architect – EA
(SPARKS, 2000)3.8.1 Área de Trabalho
Área de trabalho, composta por diferentes janelas.
1. O navegador de Projetos permite que você navegue pelo projeto. Utilize o clique duplo nos pacotes (packages) para abri-los. O clique com botão direito permite visualizar as opções do menu sensível ao contexto para elementos de projeto.
2. As Propriedades são um conjunto de abas para notas, propriedades de objeto, requisitos e outros.
3. Na área principal está o Diagrama. É nesta área que você irá colocar novos elementos de modelo e poderá modificar suas características.
4. A Barra de Objetos (object toolbar) permite que você possa selecionar e criar elementos de modelo e relacionamentos.
3.8.2 Navegador de Projetos
O Navegador de Projetos funciona de maneira semelhante à um navegador de diretórios e arquivos (como por exemplo o Windows Explorer), mas gerenciando o desenvolvimento do projeto, e desta forma, exbindo os pacotes, diagramas, objetos e propriedades de objeto.
3.8.3 Etapas de desenvolvimento
1. Criação da Visão de Negócios completa 2. Definição da visão geral da arquitetura técnica 3. Criação dos aspectos funcionais
4. Aprovação dos aspectos funcionais definidos pelo analista de negócios 5. Criação dos diagramas de caso de uso, atividades e sequência
6. Criação das interfaces com o usuário 7. Criação dos diagramas de classe 8. Criação dos esquemas de dados 9. Geração do código
4
Modelagem de Processos de Negócio com UML
4.1 Modelagem de Processos de Negócios com UML
(SPARKS, 2000)A modelagem de processos de negócios é uma parte essencial de qualquer procedimento de desenvolvimento de software. A modelagem permite ao analista capturar um grande esboço e procedimentos relacionados com o que é um negócio faz. Desta forma, estes modelos fornecem uma visão geral da proposta do sistema de software que é considerado e que estará ajustado para a estrutura organizacional e as atividades diárias. Também, associado ao custo-benefício, pode prover a justificação para construir o sistema novo baseado no manual atual e outros procedimentos automatizados.
Os modelos de processos de negócios permitem ao analista capturar eventos, insumos, recursos e produtos associados a estes processos. Depois são inseridas neste modelo ligações (como Casos de Uso) que permitem construir outros modelos a partir dos processos esboçados, isto para inserir os requerimentos funcionais e eventualmente para os requerimentos dos artefatos de software que serão construídos.
Como os modelos de processos de negócios têm tipicamente um alcance maior e mais inclusivo que o sistema de software que é considerado, também permitem ao analista mapear claramente o que está no âmbito do sistema proposto e o que será implementado em outra oportunidade (por exemplo o manual de processos).
Notação da modelagem de processos
Um modelo de processo de negócio define os elementos a seguir:
Os objetivos, metas ou a razão do processo;
Insumos (entradas) específicos;
Produtos (saídas) específicos;
Recursos consumidos;
Atividades que são executadas em alguma ordem; e
Eventos que dirigem o processo. O processo de negócio:
Pode afetar mais de uma unidade organizacional;.
Tenha um impacto organizacional horizontal;
Cria valor de algum tipo pelo cliente. Clientes podem ser internos ou externo
O processo de negócio
Um processo de negócio é uma coleção de atividades projetadas para produzir um produto específico para um cliente particular ou mercado. Implica uma ênfase forte em como o trabalho é realizado dentro de uma organização. Um processo é assim um conjunto específico de atividades
de trabalho por tempo e considera um começo, um fim, e claramente define insumos e produtos através de uma estrutura para ação.
A notação usada para descrever um processo de negócio é ilustrada abaixo.
A notação de processo implica um fluxo de atividades desde a esquerda para a direita. Normalmente o elemento evento é colocado à esquerda do processo e o produto (saída) à direita. Nota-se especificamente que as atividades internas, elementos de atividades UML podem ser colocados dentro do elemento processo.
Entradas, Recursos e Informação
Processos de negócios utilizam informações para completar as suas atividades. Diferentes informações e recursos são utilizados no processo de transformação. A informação pode vir de fontes externas, de clientes, de unidades organizacionais internas e pode ser até mesmo o produto de outros processos.
Um recurso é um insumo (entrada) a um processo de negócio, sendo que a informação usada é distinta que a utilizada durante o processo. Por exemplo, cada serviço de trem diário é executado e registrado de forma atualizada e o recurso de serviço é 'sempre usado' até onde o processo de gravação dos tempos do trem sejam considerados.
As notações para ilustrar as informações e recursos são mostradas abaixo.
A ligação 'supply' (fornecer) indica que a informação ou objeto ligado no processo não é usado na fase de processamento. Por exemplo diferentes formas e estilos de ordens dos clientes podem ser utilizados como parte desta atividade.
A ligação 'input' (insumo) indica que o objeto ou recurso ligado é utilizado no processamento. Por exemplo, as ordens completadas e assinadas dos clientes são processadas pelo recurso.
Evento
Um evento é uma entrada para um objeto, um tempo ou data alcançada, uma notificação ou o início de um processo de negócio. Estes eventos podem ser utilizados e transformados (por exemplo uma ordem de cliente) ou simplesmente age como um catalisador (por exemplo trabalho de grupo a noite).
Produtos
Um processo de negócio produzirá um ou mais produtos que agreguem valor para o negócio. Um produto pode ser um objeto físico (como um relatório ou fatura), uma transformação de recursos crus em um novo arranjo (um horário diário ou lista) ou um resultado do negócio global tal como o complemento de uma ordem de cliente. Um produto de um processo de negócio pode alimentar um outro processo ou iniciar novas atividades.
A ligação 'output' (produto) indica que o processo de negócio produz algum objeto (físico ou lógico) que é de valor para a organização, como um item externamente visível ou como um produto interno (alimentando outro processo possivelmente).
Objetivos e metas
Um processo de negócio tem alguma meta e objetivo bem definido. Esta é a razão porque a organização faz este trabalho e deveria ser definido em termos de benefícios que este processo traz para a organização como um todo e satisfazendo as necessidades do negócio.
A ligação 'goal' (meta) indica e descreve o objeto definido o processo de negócio, sendo que esta meta é uma justificativa do negócio para executar as atividades.
Juntando as partes
O diagrama a seguir ilustra como os vários elementos do modelo podem se agrupar para produzir um quadro coerente de um processo de negócio definido. São incluídos os insumos, produtos, eventos, metas e outros recursos importantes.
Relacionamento
Um relacionamento define o modo com que um determinado processo de negócio será implementado no sistema proposto. Em um diagrama de implementação, casos de uso, pacotes e outros artefatos de modelos podem ser ligados detrás do processo de negócio com <<implement>>. O exemplo a seguir ilustra como um processo de negócio é implementado por um Caso de Uso e um pacote. Como o modelo desenvolvido e o os componentes do software funcional são construídos e ligados ao Caso de Uso, a justificação do negócio para cada elemento pode ser derivada deste modelo.
O Processo de negócio inclui um grande alcance do manual e de procedimentos automatizados. Este modelo ilustra que funcionalidade (Caso de Uso) que será construído para servir um particular processo de negócio: qualquer funcionalidade perdida tem que vir de outros sistemas e procedimentos (manual ou automatizado).
Um exemplo
O exemplo a seguir apresenta um modelo que pode ser construído para representar um processo de negócio. Neste modelo, a meta do processo de negócio é levar a ordem do cliente e transportar essas (ordens) para fora. Um usuário começa o processo mediante uma investigação, que determina o envolvimento com o catálogo de livros, carrinho de compras, páginas on-line e estoques. O produto de significância para o negócio é uma ordem do cliente.
EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg is te re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion E A 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion EA 3 .1 0 - U nreg iste re d T ria l V er sion « p ro c e s s » Adm inis tr a ç ã o d e or de n s Ca tá log o d e Livr o s P á g in a s W e b « p ro c e s s » V e n d a de livr os o n -line O rd e m d o c lie n te Ca r tã o de c o m pr a Us u á r io O r d e m « g o a l» L e va r a o r d e m d o c lie n te Es toq u e P e s q u is a « g o a l» O r d e m d e s p a c ha d a O r d e m e ntr e gu e T r a ns p or te d a c om p a nh ia Ite m do c a r tã o
A m o d e la g e m d e p ro ce s s o s d e n e g ó c io a p re s e n ta a s p rin cip a is a tivid a d e s d a o rg a n iza ç ã o . U m p ro ce s s o flu ir p o r m u ito s d e p a rta m e n to s o u d ivis õ e s d e u m a e m p re s a e e le d e s cre ve o q u e u m n e g ó c io re a liza , e n fo c a n d o p rin cip a lm e n te p ro d u to s , p ro d u to s , m e ta s e e ve n to s ch a ve q u e in flu e n cia m o p ro c e s s o . < < s u p p ly> > < < in p u t> > < < in p u t> > 1 0 ..n < < u s e s > > < < o u tco m e > > < < s u p p ly> > « s u p p ly» < < o u tco m e > >
A segunda parte da modelagem do processo é representar a ordem do cliente e transportar os artigos exigidos. O segundo processo envolve os estoques e transporte do depósito da companhia e é finalizada quando a ordem é entregue ao cliente.
4.2 Modelo de casos de uso
O modelo de Casos de Uso foi proposto por I. Jacobson como um instrumento para descrição das intenções ou requisitos para um sistema computacional. A construção do Modelo de Casos de Uso corresponde a uma das fases iniciais de um projeto de software pois envolve a determinação dos usos que o sistema terá, ou seja, do que ele devera fornecer como serviços.
O modelo de Casos de Uso é diferente da visão funcional utilizada no passado nas abordagens de projeto estruturado. Ao invés de focalizar as funções (atribuições ou técnicas) do sistema, o modelo de Casos de Uso captura os usos ou aplicações completas do sistema. Este modelo busca responder a questão: Que usos o sistema terá ? ou Para que aplicações o sistema será empregado?
Os modelos de Casos de Uso são descritos através de Diagramas de Casos de Uso na UML. De uma forma geral, cada projeto de software conterá um Diagrama de Casos de Uso. Para sistemas mais extensos, é possível decompor o diagrama em um conjunto de sub-diagramas.
Uma vez construído o modelo de Casos de Uso, o restante do projeto pode ser guiado baseando-se neste modelo. Dito de outra forma, a partir do modelo de Casos de Uso, o restante do projeto ira se preocupar com a forma de realização dos casos de uso (que classes e objetos são necessários, como e quando cada um atuara , etc).
O modelo de Casos de Uso é um instrumento eficiente para determinação e documentação dos serviços a serem desempenhados pelo sistema. Ele é também um bom meio para comunicação com os clientes no processo de definição dos requisitos do sistema.
4.3 Diagramas de Casos de Uso (
STADZSIZ, 2002)Os casos de uso de um projeto de software são descritos na linguagem UML através de
Diagramas de Casos de Uso. Estes diagramas utilizam como primitivas Atores, Casos de Uso e
Relacionamentos. Como ocorre também com outros diagramas, pode-se ainda utilizar as primitivas Pacote e Nota nos diagramas de casos de uso. As subseções a seguir descrevem estas primitivas.
4.3.1 Atores
Atores são representações de entidades externas mas que interagem com o sistema durante sua execução. Basicamente, a interação de atores com o sistema se da através de comunicações (troca de mensagens). As entidades externas representadas pelos atores podem ser :
Pessoas: usuário, secretária, aluno, professor, administrador, etc.
Dispositivos: impressora, máquina ou outros equipamentos externos
Hardwares: placa de modem, placa de controle, etc..
Software: sistema de banco de dados, aplicativos, etc.
É importante observar que atores representam, na verdade, papeis desempenhados por pessoas, dispositivos ou outros softwares quando estiverem interagindo com o sistema. Por exemplo, um ator cujo identificador seja Aluno não representa um aluno específico mas sim um aluno qualquer, ou seja, uma pessoa qualquer que esteja interagindo com o sistema na qualidade de aluno. Desta forma, um ator pode representar um entre vários indivíduos, equipamentos ou
softwares. De forma análoga, uma entidade externa pode ser representada na forma de vários atores.
Isto ocorre quando a entidade tem mais de um papel (tipo de participação ou interação) no sistema. Por exemplo, o indivíduo João da Silva poderia ser representado em um sistema na forma do ator Usuário, pois ele interage com o sistema nesta qualidade, e também na forma do ator Administrador, pois ele também interage com o sistema para este outro fim que é a administração do software.
Atores são representados através de retângulos (notação genérica para classe) usando a simbologia padrão da UML ou através de ícones humanos. As duas notações são sintaticamente equivalentes, porém a segunda é seguramente mais intuitiva. A desvantagem do uso de ícones humanos ocorre quando o ator representa equipamentos, dispositivos de hardware ou outros
softwares. Neste caso, a figura humana não coincide com a natureza do ator. E possível, entretanto,
através de mecanismos de extensão, criar grafismos especiais ou especializados na UML para indicar tipos de atores.
Observe que a notação usando retângulos exige a inserção de um classificador para indicar a natureza daquilo que se esta representando. No caso de atores, deve-se incluir o classificador (ou estereótipo) <<ator>> antes do nome do ator. Quando se utiliza o ícone humano, basta indicar o nome do ator abaixo do ícone.
O levantamento dos atores que interagem com um certo sistema depende de um trabalho de estudo que envolve discussões com os clientes. Procura-se neste estudo levantar as pessoas que serão beneficiadas e que usarão o sistema. Além disso, deve-se levantar os dispositivos e softwares com os quais o sistema devera se comunicar. Para muitos projetos, pode não ser fácil levantar corretamente o conjunto de atores na primeira tentativa. O estudo dos casos de uso e dos relacionamentos com atores podem permitir refinar o conjunto de atores definidos. O estudo das classes do sistema, a ser feito na próxima fase, também ira contribuir para o refinamento do levantamento de atores.
Embora a UML não imponha restrições, costuma-se considerar determinados atores como atores implícitos. Desta forma estes atores não aparecem no diagrama de casos de uso embora eles estejam presentes e participem da execução dos casos de uso. Os atores implícitos representam essencialmente dispositivos e softwares que são sempre usados e que não impõem protocolos especiais de comunicação. Desta forma, a supressão destes atores não traz nenhum efeito significativos sobre os modelos e simplifica as representações. Os exemplos mais comuns de atores que se pode considerar como implícitos são: monitor de vídeo, teclado, mouse, auto-falante, microfone, unidade de disco e sistema operacional. Estas entidades serão atores legítimos mas cuja inclusão no modelo de casos de uso não traz contribuição para a modelagem.
4.3.2 Casos de Uso
A descrição dos serviços a serem oferecidos pelo sistema é feita na UML discriminando-se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicação ou uso completo do
software. O conceito de caso de uso não deve ser confundido com o de módulo já que um caso de
uso não é um componente do sistema mas sim um de seus empregos possíveis.
Também não se deve confundir o conceito de caso de uso com o de função que possui um escopo muito mais limitado, traduzindo freqüentemente apenas um recurso ou utilidade do sistema. Um caso de uso é muito mais abrangente, envolvendo todo um conjunto de transações que juntas constituem um serviço completo oferecido pelo sistema.
A especificação das funcionalidades de um sistema na forma de casos de uso permite uma visão mais abrangente das aplicações do sistema facilitando um levantamento mais completo e preciso de suas atribuições
.
4.4 Relacionamentos entre Atores e Casos de Uso
Os relacionamentos em um diagrama de casos de uso podem envolver dois atores, dois casos de uso ou um ator e um caso de uso, conforme descrito nas subseções seguintes.
4.4.1 Relacionamentos entre Atores
Como os atores são entidades externas, os relacionamentos entre eles serão relações externas ao sistema. Embora estas relações possam ser desprezadas, pois não fazem parte do sistema e nem são de conhecimento do sistema, é possível incluí-las no modelo de casos de uso. De certa forma, estas relações descrevem parte do modelo de negócio da empresa. As duas relações mais comuns entre atores são a comunicação (ou associação) e a especialização (ou generalização). Um relacionamento de comunicação indica que os dois atores, de forma uni ou bidirecional, realizam uma comunicação (troca de informação ou de mensagem) que possui um significado formal para o sistema modelado. No exemplo da Figura 4.1, o ator Aluno comunica-se com o ator Secretaria no sentido que transmitir uma Solicitação de Histórico Escolar. Trata-se de uma comunicação explícita cuja ocorrência deve ter alguma repercussão ou significado para o sistema. Um relacionamento de
generalização, por outro lado, representa uma relação conceitual entre atores indicando que um ator é um caso especial de outro ator mais genérico. Esta relação indica que o ator especializado inclui todos os atributos do ator genérico e inclui ainda atributos adicionais. Como ilustra a Figura 4.2, o ator Administrador é um ator especializado do ator Usuário. Isto significa que o Administrador é um Usuário com atributos ou características extras. De certa forma, o ator especializado estende o ator genérico.
Figura 4.2 - Exemplos de relações entre atores
4.4.2 Relacionamentos entre Atores e Casos de Uso
O relacionamento entre um ator e um caso de uso expressa sempre uma comunicação entre eles, pois o ator sendo uma entidade externa não poderia possuir qualquer relacionamento estrutural com o sistema computacional. A notação UML para este tipo de relacionamento é um segmento de reta ligando ator e caso de uso, como ilustrado na Figura 4.3. Em diagramas mais complexos pode-se utilizar cadeias de segmentos de retas para se evitar cruzamentos. Como atores podem ter vários propósitos, no que diz respeito a suas interações com o sistema, podem existir mais de um relacionamento de um ator com diferentes casos de usos.
De forma análoga, um mesmo caso de uso pode envolver a participação de mais de um ator. A Figura 4.3 ilustra estas situações. O caso de uso Emitir Histórico Escolar envolve a participação de dois atores: Secretaria e Impressora. O ator Secretaria participa em dois casos de uso: Emitir Histórico e Registrar Novo Aluno.
Figura 4.3 - Exemplos de relações entre Atores e casos de Uso
A utilização de setas nas relações entre atores e casos de uso pode ter duas interpretações distintas. Na primeira, utilizam-se setas para indicar qual ator ativa o caso de uso. Ativação neste caso significa, quem lança ou inicia a execução do caso de uso. Para sistemas interativos, freqüentemente é o ator Usuário quem ativa o caso de uso. Na situação mais comum, cada caso de uso só teria um ator contendo uma seta em seu relacionamento de comunicação. É possível, entretanto, haver mais de um ator ativador para um mesmo caso de uso significando que um deles ativaria este caso de uso. No exemplo na Figura 4.3 aplica-se esta interpretação das setas. A segunda interpretação para as setas é a indicação do sentido do fluxo de dados nas comunicações. Neste caso todas as relações entre atores e casos de uso teriam setas em uma ou nas duas extremidades descrevendo o sentido da comunicação com cada ator. As duas interpretações são
possíveis mas deve-se optar por uma delas em cada projeto e indicar explicitamente a interpretação adotada.
4.4.3 Relacionamentos entre Casos de Uso
Ao contrário do relacionamento entre ator e caso de uso, as relações entre casos de uso nunca será do tipo comunicação. Isto ocorre porque casos de uso são aplicações completas do sistema e, por conseqüência, não existe sentido em fazer-se comunicar dois ”usos do sistema”. Todas as relações entre casos de uso serão sempre estruturais. Existem três tipos de relações entre casos de uso (inclusão, extensão e generalização) conforme descritos a seguir.
Relacionamento de Inclusão
Um relacionamento de inclusão é uma relação estrutural através da qual um caso de uso insere em seu interior um outro caso de uso. O caso de uso incluído (subcaso de uso) não representa um serviço completo do sistema mas uma porção de um serviço. Isoladamente, um subcaso de uso não teria sentido. Ele será sempre um integrante de um caso de uso maior e completo. O relacionamento de inclusão se aplica a duas situações principais. A primeira aplicação da Inclusão é para o detalhamento de casos de uso através de decomposição. Nesta situação, extraem-se partes significativas de um caso de uso criando-se subcasos de uso ligados ao caso de uso maior através de relações de inclusão. Embora raro, é possível ainda decompor subcasos de uso em outros subcasos de uso. Uma segunda aplicação do relacionamento de inclusão é a de colocar em evidência as partes comuns a dois ou mais casos de uso. Nesta situação o subcaso de uso é incluído por mais de um caso de uso maior. A Figura 4.4 ilustra estas duas situações.
Figura 4.4 - Exemplo de Relacionamento de Inclusão entre Casos de Uso
Relacionamento de Extensão
Um relacionamento de extensão é uma relação estrutural entre dois casos de uso através da qual um caso de uso maior é estendido por um caso de uso menor. A extensão significa que o caso de uso que estende inclui serviços especiais em um caso de uso maior. A definição de um relacionamento de extensão inclui a especificação de uma condição de extensão. Esta condição habilita a extensão, ou seja, indica quando aplicar o relacionamento. A notação para o relacionamento de extensão é ilustrada na Figura 4.5.
Figura 4.5 - Exemplo de Relacionamento de Extensão entre Casos de Uso
A diferença principal entre os relacionamentos de inclusão e extensão é o caráter de excepcionalidade da extensão. Extensões são usadas para modelar casos especiais e de exceção que ocorrem somente em certas situações (dado pela condição). Desta forma, para a maioria das ocorrências do caso de uso estendido, a extensão não se aplicara.
Relacionamento de Generalização
Um relacionamento de generalização é uma relação estrutural entre um caso de uso mais geral e um caso de uso mais específico. O caso de uso mais geral representa o caso genérico cujo serviço se aplica a várias situações. O caso de uso mais específico representa a aplicação do caso uso mais geral em uma situação particular incluindo elementos adicionais ou estendendo este caso. Visto no outro sentido, o caso de uso mais geral é uma generalização (abstração) do ou dos casos de uso mais específicos. Neste sentido, o caso de uso geral, representa as partes comuns de casos de uso especializados.
A notação UML para a generalização envolve a ligação dos dois casos de uso através de um segmento de reta e a colocação de um triangulo na extremidade do caso de uso mais geral. A Figura 4.6 apresenta um exemplo de relacionamento de generalização.
Figura 4.6 - Exemplo de Relacionamento de Generalização entre Casos de Uso
No exemplo da Figura 4.6, tem-se um caso de uso mais geral, chamado Emitir Histórico Escolar, que permite a secretaria imprimir históricos de alunos. Quando o aluno conclui na totalidade o curso, ele pode solicitar um histórico de conclusão. Este histórico é semelhante ao histórico normal mas é mais detalhado incluindo informações adicionais. O caso de uso Emitir Histórico Escolar de Conclusão é portanto semelhante ao caso de uso Emitir Histórico Escolar mas com alguns elementos adicionais. Pode-se, como feito no exemplo, estabelecer uma relação de especialização entre os dois casos de uso.
A relação estrutural definida por um relacionamento de generalização implica a incorporação (herança) dentro do caso de uso especializado de todo o serviço especificado pelo caso de uso geral, incluindo, adaptando ou excluindo alguns serviços oferecidos pelo caso de uso geral. O relacionamento de generalização não pode ser confundido com os de inclusão e extensão pois a generalização se aplica, na maior parte dos casos, a compartilhamentos de maior dimensão. A inclusão e extensão envolvem partes menores de casos de usos. A natureza da generalização também é distinta pois trata-se de especificar modelos (casos de uso) genéricos aplicáveis a diferentes situações. A inclusão e a extensão apenas põem em evidencia partes de casos de uso maiores.
4.5 Decomposição de Diagramas de Casos de Uso
Um projeto de software, normalmente, conterá um Único Diagrama de Casos de Uso descrevendo o conjunto de serviços oferecidos pelo sistema. Para sistemas maiores ou mais complexos, entretanto, é possível a construção de vários diagramas de casos de uso elaborados a partir da decomposição de um diagrama principal.
A decomposição de um diagrama de casos de uso pode ser feita em UML utilizando o conceito de Pacote (package). Um pacote é um encapsulador que não possui uma semântica específica dentro dos projetos. Ele é usado essencialmente para separar ou agrupar elementos do projeto sem criar necessariamente com isso algum vínculo entre os elementos. Utilizando pacotes pode-se criar um primeiro diagrama contendo todos os pacotes maiores do sistema e, a seguir, tomar cada pacote e expandí-lo em um novo diagrama. Pode-se construir uma hierarquia com vários níveis de decomposição conforme a dimensão do sistema e o número de casos de uso e atores.
Os elementos (casos de uso e atores) dentro de um pacote podem ter relacionamentos com elementos de outros pacotes. Neste caso existe uma dependência entre pacotes. As dependências devem ser explicitamente definidas utilizando como notação um segmento de reta tracejado com uma seta no sentido do pacote que depende para o pacote que contém as dependências. A Figura 4.7 ilustra a notação utilizada para pacotes e dependências.
Figura 4.7 - Exemplo de Pacotes e Dependências
Não existe uma norma para separação dos casos de uso e atores em pacotes. Pode-se, por exemplo, agrupar dentro de um pacote casos de uso de naturezas semelhantes (casos de uso de cadastro, casos de uso de emissão de relatórios, etc) ou casos de uso envolvendo os mesmos atores. De forma geral, procura-se reunir casos de uso que possuem relacionamentos em um mesmo pacote. Quando um ator ou caso de uso tiver que aparecer em mais de um pacote, define-se este ator ou caso de uso em um pacote e copia-se o ator ou caso de uso nos demais pacotes. Neste caso, deve-se indicar nos demais pacotes qual o pacote de origem daquele ator ou caso de uso.
4.6 Exemplo
Para ilustrar a aplicação do conceito de caso de uso, desenvolve-se nesta seção um exemplo de modelagem para um sistema de controle acadêmico. Embora, o desenvolvimento completo de um modelo de casos de uso possa envolver várias iterações de refinamento, para fins didáticos o exemplo deste seção apresentará a modelagem através de 4 fases.
Fase 1 : Levantamento dos Atores
O sistema de controle acadêmico considerado neste exemplo será utilizado na secretaria de um determinado curso. No que diz respeito aos indivíduos envolvidos, somente o pessoal da secretaria terá acesso ao sistema. Entre as pessoas que atuam na secretaria e poderiam utilizar o sistema estão os chefes da secretaria, a secretaria, alguns professores e alguns estagiários. Na verdade, apesar de se tratarem de indivíduos diferentes, quando estiverem utilizando o sistema todos assumirão o mesmo papel, ou seja, todos atuarão na forma de um ator abstrato que pode ser denominado Secretaria.
Preliminarmente, supõe-se que alguns documentos deverão ser impressos pelo sistema, o que sugere a criação de um ator denominado Impressora com o qual o sistema ira interagir para a impressão de documentos (histórico escolar, diário de classe, etc). O ator impressora poderia ser considerado um ator implícito mas pode ser ilustrativo fazê-lo aparecer explicitamente no modelo.
Como o volume de informações (alunos, professores, disciplinas, etc) pode ser grande optou-se pelo uso de um Sistema Gerenciador de Banco de Dados para armazenamento dos dados acadêmicos. Como se trata de um sistema computacional independente com o qual o sistema de controle acadêmico ira interagir, ele deve ser considerado também como um ator.
Neste exemplo, este ator será denominado SGBD. Portanto, os atores que foram inicialmente levantados são:
Figura 3.8 - Atores do sistema de controle acadêmico.
Na prática, nem sempre é possível determinar todos os atores e defini-los corretamente na primeira tentativa. Se for considerada uma abordagem de projeto por refinamentos sucessivos, a lista de atores poderia ser melhorada, assim como a definição destes atores, a medida que o projeto avance quando mais informações estiverem disponíveis.
Fase 2 : Levantamento dos Casos de Uso Principais
Nesta fase busca-se definir a lista dos grandes serviços que o sistema devera oferecer. O levantamento dos casos de uso corresponde a uma análise de requisitos e deve ser desenvolvido a partir de informações coletadas dos clientes. Através de questionários e reuniões com os clientes procura-se definir quais são as aplicações ou usos desejados para o sistema a ser desenvolvido.
Para o sistema de controle acadêmico considera-se que os clientes (usuários, professores e administração da escola) desejam que o sistema ofereça os seguintes serviços:
possibilidade de cadastramento de todos os alunos matriculados no curso. Isto implica um
serviço para inclusão de novos alunos e para manutenção da base de dados dos alunos. Este uso do sistema será representado pelo caso de uso Cadastrar Aluno.
possibilidade de cadastramento de todos os professores que ministram disciplinas no
curso. Isto implica um serviço para inclusão de novos professores e para a manutenção da base de dados de professores. Este uso do sistema será representado pelo caso de uso Cadastrar Professor.
possibilidade de registro das disciplinas oferecidas no curso incluindo o registro de novas
disciplinas e a manutenção da base de dados de disciplinas. Este serviço ou uso do sistema será representado pelo caso de uso Cadastrar Disciplina.
possibilidade de registro da matrícula de alunos em disciplinas a cada semestre. Este
possibilidade de emissão da confirmação de matrícula para cada aluno contendo a lista de
disciplinas nas quais um aluno se matriculou para aquele semestre. Este serviço será representado pelo caso de uso Emitir Confirmação de Matrícula.
possibilidade de emissão do diário de classe para cada disciplina contendo a lista de
alunos matriculados naquele semestre. Este serviço será representado pelo caso de uso Emitir Diário de Classe.
possibilidade de lançamento das notas obtidas pelos alunos em cada disciplina ao final de
cada semestre. Este serviço será representado pelo caso de uso Registrar Nota.
possibilidade de emissão do histórico escolar para cada aluno contendo a lista de
disciplinas cursadas e respectivas notas. Este serviço será representado pelo caso de uso Emitir Histórico Escolar.
O conjunto de casos de uso levantados representa os serviços ou usos esperados pelos clientes que utilizarão o sistema. Assim como para os atores, nem sempre é possível efetuar um levantamento completo e definitivo dos casos de uso em uma primeira tentativa. Ao longo do processo de refinamento, novos casos de uso poderiam aparecer ou outros sofrerem alterações.
A Figura 4.9 ilustra os casos de uso definidos para o sistema acadêmico.
Figura 4.9 - Casos de Uso do Sistema de Controle Acadêmico
Fase 3 : Definição dos Relacionamentos
Nesta fase são estabelecidos os relacionamentos de comunicação entre os atores e os casos de uso indicando quais atores participam (se comunicam) com quais casos de uso. Para o exemplo em estudo, o resultado seria aquele apresentado na Figura 4.10. Neste diagrama de casos de uso, adotou-se o uso de setas nas relações para indicar qual ator é responsável pela ativação dos casos de uso.
Fase 4 : Detalhamento dos Casos de Uso
Nesta fase é feito um detalhamento dos casos de uso através de decomposições ou especializações. O grau de detalhamento necessário é um aspecto subjetivo. Cabe ao projetista julgar qual o bom nível de detalhamento para cada projeto. Não se deve exagerar nas decomposições sob o risco de se estar influenciando ou direcionando o processo de projeto.
Deve-se lembrar que os diagramas de casos de uso são especificações do que o sistema deve fazer e não de como ele devera realizar os serviços.
Como abordagem geral para esta fase existem as seguintes sugestões:
Procure estimar a dimensão de cada caso de uso. Para casos de uso muito extensos, crie subcasos de uso que identifiquem partes do processo envolvido naquele caso de uso. Relacione os subcasos de uso com caso de uso maior através de relações de inclusão. Para o sistema de controle acadêmico, considerou-se que os três casos de uso para cadastramento (aluno, professores e disciplinas) têm uma dimensão