Introduo a UML A UML foi desenvolvida com a finalidade de especificar, visualizar, documentar e construir artefatos de um sistema de software, tendo

como objetivo maior padronizar entre a comunidade, desenvolvedores e projetista de softwares Orientados a Objeto, um meio comum de comunicao. O que Unified Modeling Language (UML)? Unified Model Language Linguagem de modelagem unificada. O que um modelo? Um modelo uma simplificao da realidade. UML projetado especificamente para representar sistemas orientados a objetos (OO). Tcnicas de desenvolvimento orientado a objetos descrevem software como um conjunto cooperativo de blocos de informao e comportamento. Por exemplo, uma performance em um teatro seria codificada como um mdulo discreto com seus prprios dados de datas e horas, e no comportamento tais como o cronograma, cancelar ou remarcar todos os planos em conjunto. Esta foi uma partida dura da antiga noo de que os dados residem em arquivos e comportamento em programas. O efeito desta idia simples, a combinao de dados e comportamento em objetos, teve um efeito profundo no design da aplicao. J em 1970, uma srie de mtodos foram desenvolvidos para explorar a nova orientao a objetos (conceitos de orientao a objetos) de programao. Desenvolvedores rapidamente reconheceram que a orientao a objetos tornou possvel um processo de desenvolvimento no qual a maneira que eles falam sobre a aplicao corresponde diretamente a forma como codific-lo. Eles tambm descobriram que era relativamente fcil de desenhar (modelo) dos objetos para que eles pudessem falar sobre o projeto. Cada objeto foi representado como um elemento em um diagrama. Porque os elementos do modelo foram quase idnticos aos elementos de cdigo, a transio do modelo de cdigo era simples e eficiente. Movendo discusses de concepo at os modelos ao invs do cdigo ajudando a lidar com questes dos desenvolvedores do projeto em um alto nvel de abstrao, sem ter de se prender na sintaxe de codificao. Existem limites para a capacidade humana de compreender complexidades. Com ajuda da modelagem, delimitamos o problema que estamos estudando, restringindo nosso foco a um nico aspecto por vez. Em essncia esse o nico procedimento de dividir e conquistar, do qual Edsger W.Dijkstra falava h anos. Quais so os objetivos da UML? 1. Permitir a modelagem de sistemas (no apenas de software) usando conceitos orientados a objetos; 2. Estabelecer um acoplamento explcito com artefatos conceituais e executveis; 3. Resolver questes de escala inerentes a sistemas complexos e de misso crtica; 4. Criar uma linguagem de modelagem utilizvel por humanos e mquinas.

A UML uma linguagem para documentao Uma empresa saudvel produz todos os tipos de artefatos alm do cdigo executvel bruto. Esses artefatos incluem (mas no esto limitados a) o seguinte: Requisitos; Arquitetura; Projeto; Cdigo-fonte; Plano do projeto; Testes; Prottipos; Verses. Blocos de construo O vocabulrio da UML abrange trs tipos de blocos de construo: Itens; Relacionamentos; Diagramas. Os itens so abstraes identificadas como cidados de primeira classe em um modelo; os relacionamentos renem esses itens; os diagramas agrupam colees interessantes de itens. Itens da UML Itens estruturais; Itens comportamentais; Itens de agrupamentos; Itens anotacionais. Itens estruturais So os substantivos utilizados em modelos da UML. So as partes mais estticas do modelo, representam modelos conceituais ou fsicos. Chamados de classificadores. Classes: so descries de conjuntos de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. As classes implementam uma ou mais interfaces.
Cliente Nome : String Idade : Num Criar() Destruir()

Nome da Classe Atributos Operaes

Figura 1- Exemplo de Classe. Interfaces: uma coleo de operaes que especificam servios de uma classe ou componentes. Uma interface descreve o comportamento externamente visvel desse elemento. A declarao de uma interface

semelhante a de uma classe porm com o seguinte esteretipo (palavra-chave) <<interface>> acima do nome. Dificilmente apresentam os atributos. Colaboraes: definem interaes e so sociedades de papis e outros elementos que funcionam em conjunto para proporcionar um comportamento cooperativo superior soma de todos os elementos. As colaboraes contm dimenses estruturais, assim como comportamentais. Uma determinada classe poder participar em vrias colaboraes. Assim, essas colaboraes representam a implementao de padres que formam um sistema. Casos de uso: a descrio de seqncias de aes realizadas pelo sistema que proporcionam resultados observveis de valor para determinado ator. Um caso de uso utilizado para estruturar o comportamento de itens em um modelo. Um caso de uso realizado por uma colaborao. Classes ativas: so classes cujos objetos tm um ou mais threads ou processos e, portanto, podem iniciar a atividade de controle. Uma classe ativa semelhante a uma classe, exceto pelo fato de que seus objetos representam elementos cujo comportamento concorrente com o de outros elementos. Componentes: so partes modulares de um sistema, que ocultam a sua implementao atrs de um conjunto de interfaces externas. Em um sistema, os componentes que compartilham as mesmas interfaces podem ser substitudos ao mesmo tempo e que preservam o mesmo comportamento lgico. A implementao de um componente pode ser expressa por meio da ligao de peas e conectores; as peas podem incluir componentes menores. Artefatos: uma pea fsica substituvel de um sistema que contm informaes fsicas (bits). Em um sistema, voc encontrar diferentes tipos de artefatos de implementao, como arquivos de cdigos-fonte, executveis e scripts. Um artefato normalmente representa uma embalagem fsica da fonte ou as informaes de tempo de execuo. N: um elemento fsico existente em tempo de execuo que representa um recurso computacional, geralmente com pelo menos alguma memria e, frequentemente, capacidade de processamento. Um conjunto de componentes poder estar contido em um n e tambm poder migrar de um n para outro. Dos elementos acima apresentados tem-se que so os elementos bsicos que podem ser includos em um modelo UML. Desses surgem suas variaes: Classes; o Atores; o Sinais; o Utilitrios. Classes ativas; o Threads; o Processos. Artefatos. o Aplicaes

o o o o o

Documentos; Arquivos; Bibliotecas; Pginas; Tabelas.

Itens comportamentais Os itens comportamentais so as partes dinmicas dos modelos de UML. So os verbos de um modelo, representando comportamentos no tempo e no espao. Ao todo, existem dois tipos principais de itens comportamentais. Interao: um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em determinado contexto para a realizao de propsitos espeficos. O comportamento de uma sociedade de objetos ou de uma operao individual poder ser especificada por meio de uma interao. As interaes envolvem outros elementos, inclusive mensagens, aes e ligaes (as conexes entre os objetos). Mquina de estados: um comportamento que especifica as seqncias de estados pelas quais objetos ou interaes passam durante sua existncia em resposta a eventos, bem como as suas respostas a esses eventos. O comportamento de uma classe individual ou de uma colaborao de classes pode ser especificado por meio de uma mquina de estados. Uma mquina de estados abrange outros elementos, incluindo estados, transies ( o fluxo de um estado a outro), eventos (itens que disparam uma transio) e atividades (as respostas s transies). Atividade: um comportamento que especifica a seqncia de etapas que um processo computacional realiza. Em uma interao, o foco est no conjunto de objetos que interage. Em uma mquina de estado, o foco no ciclo de vida de um objeto por vez. Em uma atividade, o foco est nos fluxos entre as etapas, independente de qual objeto realiza cada etapa. Uma etapa de uma atividade chamada de ao. Semanticamente esses trs elementos costumam estar conectados a vrios elementos estruturais, classes principais, colaboraes e objetos. Itens agrupamento So as partes organizacionais dos modelos de UML. So blocos em que os modelos podem ser decompostos. Ao todo, existe apenas um tipo principal de itens de agrupamento, chamado de pacote. Pacote: um mecanismo de propsito geral para a organizao do prprio projeto, ao contrrio das classes, que organizam os constructos de implementao. Os itens estruturais , os itens comportamentais e at outros itens de grupos podem ser colocados em pacotes. Ao contrrio dos componentes (que existem em tempo de execuo), um pacote puramente conceitual (o que significa que existem apenas em tempo de desenvolvimento).

Existem variaes para pacotes como por exemplo frameworks, modelos e subsistemas. Itens anotacionais So as partes explicativas dos modelos de UML. So comentrios, includos para descrever, esclarecer e fazer alguma observao sobre qualquer elemento do modelo. Existem um nico tipo de item anotacional, chamado nota. Nota: apenas um smbolo para representar restries e comentrios anexados a um elemento ou a uma coleo de elementos. Existem 3 classificaes para os diagramas da UML:

Diagramas Comportamentais - Um tipo de diagrama que descreve caractersticas comportamentais de um sistema ou processo de negcio. Isto inclui a atividade, mquina de estado e diagramas de casos de uso, bem como os quatro diagramas de interao. Diagramas de Interao - Um subconjunto dos diagramas de comportamento que enfatizam interaes de objetos. Isso inclui a comunicao, viso geral de interao, sequncia e diagramas de tempo. Diagramas Estruturais - Um tipo de diagrama que descreve os elementos de uma especificao que so independentemente do tempo. Isto inclui a estrutura, classe composta, componente, a implantao do objeto, e diagramas de pacote.

Table 1 summarizes the thirteen, up from nine in UML 1.x, diagram types of UML 2.x. In the diagram column the links will take you to description pages for the artifact. The learning priority column indicates how important it is for a business application developer to learn the artifact (IMHO). Table 1. The diagrams of UML 2. Diagram Learning Priority Activity Diagram Depicts high-level business processes, including High data flow, or to model the logic of complex logic within a system. See UML Activity diagram guidelines. Class Diagram Shows a collection of static model elements such High as classes and types, their contents, and their relationships. See UML Class diagram guidelines. Communication Shows instances of classes, their Low Diagram interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. See UML Collaboration Description

Component Diagram

Composite Structure Diagram Deployment Diagram

Interaction Overview Diagram Object Diagram Package Diagram Sequence Diagram State Machine Diagram

Timing Diagram

Use Case Diagram

diagram guidelines. Depicts the components that compose an Medium application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. See UML Component diagram guidelines. Depicts the internal structure of a classifier (such Low as a class, component, or use case), including the interaction points of the classifier to other parts of the system. Shows the execution architecture of systems. Medium This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. See UML Deployment diagram guidelines. A variant of an activity diagram which overviews Low the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram. Depicts objects and their relationships at a point Low in time, typically a special case of either a class diagram or a communication diagram. Shows how model elements are organized into Low packages as well as the dependencies between packages. See Package diagram guidelines. Models the sequential logic, in effect the time High ordering of messages between classifiers. See UML Sequence diagram guidelines. Describes the states an object or interaction may Medium be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. See UML State chart diagram guidelines. Depicts the change in state or condition of a Low classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events. Shows use cases, actors, and their Medium interrelationships. See UML Use case diagram guidelines.

Modelagem estrutural bsica Classes As classes so os blocos mais importantes de qualquer sistema orientado a objetos. Uma classe uma descrio de um conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. So utilizadas para capturar o vocabulrio do sistema que est sendo desenvolvido

Primeiros passos Primeiramente faz-se necessria a identificao dos itens considerados importantes de acordo com uma determinada viso. Esses itens formaro o vocabulrio do sistema. importante observar o conjunto de propriedades do item escolhido que far parte do vocbulo. Termos e conceitos Uma classe uma descrio de um conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. Uma classe representada graficamente como um retngulo.

Nomes Cada classe deve ter um nome diferente de outras classes. Sozinho dito nome simples, acompanhado dito nome qualificado e seu acompanhamento dado pelo nome do pacote no qual a classe esta contida seguido por ( :: ). Exemplo de nomes: Cliente, SensorDeTemperatra, java::awt::Retngulo. Atributos uma propriedade nomeada de uma classe que descreve um intervalo de valores que as instancias da propriedade podem apresentar. Uma classe pode ter um nmero grande de atributos (sem limites impostos pela UML, mas o bom senso nos impe certas regras). No campo atributos, podem tambm ser amostrados os tipos dos atributos e um valor para esses, como mostra a figura a baixo.

Operaes a implementao de um servio que ser prestado pela classe, sendo solicitado por algum objeto da classe e que modifica seu comportamento. Assim como para os atributos, as operaes podem ser tantas quanto julgar necessrio, elas podem ser declaradas tambm com o tipo de operao e com os parmetros que sero usados por determinadas operaes em particular. Quando amostramos uma determinada operao por completo acabamos por definir a assinatura dessa operao, no podendo haver outra com o mesmo nome, que receba os mesmos parmetros e que tenha o mesmo tipo de retorno, dentro da prpria classe.

Organizao

Faz-se uso de esteritipos distintos dentro dos campos operadores e atributos para diferenciar os vrios operadores e os vrios atributos.

Responsabilidade um contrato ou obrigaes de uma determinada classe. Ao criar uma classe, voc estar criando uma declarao de que todos os objetos dessa classe tm o mesmo tipo de estado e o mesmo tipo de comportamento.

Notemos que fora adicionado um campo a mais no retngulo da classe, a UML prev a adio de campos complementares e de vital importncia, identificar o que os campos adicionais exprimem, para esses possvel o uso de qualquer linguagem textual assim como no exemplo acima onde no fora usada tags para identificar as responsabilidades, mas sim simples adornos da linguagem portugus. A UML prev a existncia de alguns poucos tipos de objetos como o caso dos objetos dos tipos: BOOLEAN, INT, FLOAT, LongInt e alguns mais, tomando que novas linguagens de programao aparecem a cada dia e novos tipos de objetos podem surgir a UML prev a declarao de novos tipos de objetos. Peguemos como exemplo o tipo Inteiro, para a UML uma linguagem nascida e desenvolvida quase que integralmente em pases de lngua estrangeira, no prev a existncia dessa varivel, para ns brasileiros fica fcil saber qual a correspondente imediata para essa varivel, seria o integer ou int como conhecida pelos desenvolvedores em JAVA, C/C++ e muitas outras. Porm como linguagem, devemos prever que ela existe para unir e no diferenciar programadores de diferences lnguas, seria ento necessria a especificao desse novo objeto. Fazendo uso do bloco primitivo retngulo declaramos nosso novo tipo de objeto da seguinte forma:

Outros tipos primitivos podem ser declarados, como o exemplo de quando um determinado sistema em desenvolvimento faz uso de algumas enumeraes, essas podero ser declaradas da mesma forma:

O esteritipo enumeration, um declarado em ingls por j estar definido na UML e sua representao muito prxima a de uma classe, porm sem operadores. Fica claro aps essa representao grfica que nosso sistema tem os valores falso e verdadeiro definidos distintamente. Tcnicas bsicas de modelagem Dicas e sugestes Relacionamentos Ao fazer a modelagem de um sistema necessrio alem de identificar os itens que formam o vocabulrio desse sistema, tambm necessrio identificar a forma pela qual esses itens se relacionam. Na modelagem orientada a objetos a trs tipos de relacionamentos especialmente importantes: Dependncias: que representam relacionamentos de utilizao entre as classes; Generalizaes: que relacionam classes generalizadas a suas especificaes; Associaes: que representam relacionamentos estruturais entre objetos. Primeiros passos Seguindo o exemplo de um arquiteto ao desenhar o relacionamento de uma casa temos que: Dependncia: So relacionamentos de utilizao. Os canos dependem do aquecedor para fornecer gua quente; Associaes: So relacionamentos estruturais entre instancias. As salas so formadas por paredes e outros itens; as prprias paredes podem ter portas ou janelas embutidas; os canos podem ser passados por dentro da parede; Generalizaes: Conectam as classes generalizadas a outras especializadas, o que conhecido como relacionamentos subclasses/superclasses ou filha/me. Janelas panormicas so grandes e com painis fixos de vidro; janelas de quartos costumam ter mais de um painel de vidro e abrir de um lado ao outro. Termos e conceitos DEPENDNCIA

GENERALIZAO

ASSOCIAO

Papel Quando uma classe participa de uma associao, ela tem um papel espefico a executar nesse relacionamento, o papel apenas a face que a classe prxima a uma extremidade apresenta classe que se encontra na outra extremidade

Multiplicidade um valor tambm colocado nas extremidades de uma associao que indica quantos objetos de cada elemento podem ser associados a um objeto do tipo de classe que se encontra nas demais extremidades. Tcnicas bsicas de modelagem Dicas e sugestes Exagerando na engenharia, voc acabar obtendo uma massa confusa de relacionamentos que tornaram o modelo incompreensvel, por outro lado, perder boa parte da riqueza de seu sistema embutida na forma de colaborao dos itens. CLASSES AVANADAS Motivao:... Ilustram os recursos estticos de um modelo. Os recursos estticos incluem classes e associaes, objetos e ligaes, e colaboraes.. Esses recursos estticos oferecem o framework no qual os elementos dinmicos do modelo so executados.

Uma classe define os comportamentos que os tipos de objetos podem oferecer. Uma associao define o tipo de relacionamento em que os objetos podem participar. Um diagrama de Implantao modela partes do hardware (e pessoa) que podem realizar trabalho. Componentes definem partes do software e procedimentos que precisam ser implantados para os processadores. Os diagramas estruturais funcionam de modo semelhante a uma planta para construo de uma casa ou um projeto para construo de um equipamento. Elas mostram as partes e como podem ser montadas, mas no podem mostrar como o produto acabado se comportar. Diagrama de Classes Esse diagrama est no ncleo do processo de modelagem de objetos. Modela as definies de recursos essenciais operao correta do sistema. Todos os outros diagramas de modelagem descobrem informaes sobre esses recursos que por fim precisam ser encaminhados ao diagrama de classes. a origem para a gerao de cdigo e o destino para a engenharia reversa. Os recursos representam pessoas, materiais, informaes e comportamentos, modelando-os em termos de suas estruturas, relacionamentos e comportamentos.

Os diagramas de classe so valiosos porque eles: Definem os recursos essenciais de um sistema; Definem relacionamentos entre recursos; Geram cdigo; Modelam o Cdigo; Oferecem um foco para todos os outros diagramas. Nome Normalmente um substantivo no singular como um Local ou Evento ou composto como EstratgiaPreos. As excees a essas regras incluem classes que representam colees de objetos. Esteretipos

<<entity>>

Conhecimento: Sabe apenas sobre si mesma e seus relacionamentos imediatos Responsabilidades: Precisa preservar sua prpria integridade, no importa onde ou quando seja usada. <<control>> Conhecimento: Sabe apenas sobre os recursos (outros tipos de objetos) que precisa manipular ou dirigir. Responsabilidades: Controla o uso e o comportamento dos recursos e outros elementos de software sua disposio. <<utility>> Uma classe utilitria no possui instancia. Em vez disso, ela representa uma coleo nomeada de atributos e operaes estticas (escopo de class).

<<enumeration>> Uma enumerao um tipo de dado definido pelo usurio,que define um conjunto de valores que no mudam (constantes).

Propriedade Serve para que os membros da equipe saibam se a descrio da classe est completa, sob reviso , finalizada e assim por diante. Voc tambm pode adicionar detalhes de auditoria como quem trabalhou na classe pela ltima vez, histrico das mudanas e um nmero para reviso. So espressas entre { }.

Modelando a visibilidade

Escopo Private (-): Dentro de uma classe;

Escopo Package (~): Dentro do mesmo pacote;

Escopo Public (+): Dentro de um sistema;

Escopo Protected (#): Dentro de uma rvore de herana.

Modelando a multiplicidade Intervalo de valores [2..5] Valor espefico [2..2] = [2] Se aparecer o valor 0, significa que o item opcional. Intervalo sem limite [2..*] Conjunto de valores discretos [2,4,8] Ordenao {isOrdered}

Modelando o Compartimento de Atributos Modelando o atributo Os atributos tem por definio: Visibilidade; Derivado (verdadeiro/falso); Nome; Tipo de dado; Multiplicidade; Valor default; String de propriedade; Designao de nvel de classe versus nvel de instncia. Notao [Visivilidade] [/] Nome [: tipo] [multiplicidade] [=default] [{string_propriedade}] Visibilidade J comentado Derivado (verdadeiro/falso); A barra indica que este atributo recebe um valor derivado. A ausncia da barra indica um valor bsico, valores bsicos so recebidos do usurio. Um valor derivado aquele que calculado (ou descoberto) usando outros dados e uma regra, ou frmula. Quando o valor dito

derivado existem outras decises de projeto a serem tomadas para tratar dos dados, de modo que o flag derivado usado como lembrete ao modelador at que haja tempo de resolver o tratamento dos dados. Nome Este precisa ser exclusivo dentro da classe. Os nomes so um local onde a brevidade no uma virtude. Se o mesmo nome aparece em vrias classe e voc precisa se referenciar a determinado nome de determinada classe, ento obrigatrio se referenciar a classe. Nome_classe.nome_atributo Tipo de dado Uma referencia a um Tipo de Dado primitivo: (Integer, UnlimitedInteger, ou String); Uma enumerao, como Boolean; Uma referencia a um tipo espefico da linguagem, como float, int, short em Java; Uma referencia a outra classe no seu sistema. Multiplicidade J comentado Valor default;

start_date recebe o valor (no_default) significando que embora seja necessrio um valor default para esta varivel simbolizado anteriormente pelo sinal de (=), o modelador no tem como presumir tal valor e (required) diz que este valor precisa ser fornecido imediatamente quando um objeto for criado. /end_date indica como a frmula do valor derivado, para que este possa ser obtido. String de propriedade; J comentado Designao de nvel de classe versus nvel de instncia. A maioria dos valores de atributo pertence a um objeto espefico, uma instncia de uma classe. Eles so chamados atributos no nvel de instancia. Um atributo no nvel da classe refere-se a um atributo que acessvel dentro da classe. Os atributos no nvel de classe tambm so chamados de atributos estticos em algumas linguagens. Como o valor definido e armazenado no interior da classe, todo o objeto da classe pode acessar esse valor. Literalmente todos os objetos do mesmo tipo compartilham o mesmo valor. Em UML 1.4 para definir um atributo como esttico este totalmente sublinhado. Em UML 2.0 foi definido (isStatic). Modelando o Compartimento de Operaes Operaes definem comportamentos, os servios que um objeto pode oferecer. A UML faz distino entre a interface para um compartimento e a

implementao de um compartimento. A interface para um compartimento a chamada de operao. Uma operao declara a informao necessria para invocar um comportamento. A operao a nica parte de um comportamento modelada no diagrama de Classes. A implementao que no modelada no diagrama de Classes, chamada de mtodo. Notao de Operao A notao define os elementos comportamentais de uma classe modelados por meio da sintaxe: [visibilidade] nome ( [lista-parmetros] ) : [resultado-retorno] [ { propriedades } ] Visibilidade privada (-): somente objetos da mesma classe podem chamar/invocar uma operao privada; pacote (~): somente objetos possudos pelo mesmo pacote podem chamar uma operao no nvel de pacote; pblica(+): Qualquer objeto pode chamar uma operao pblica, desde que o objeto que chama tenha acesso ao pacote em que a operao reside; protegida(#): Somente objetos definidos dentro da subclasses da classe que a possui podem chamar uma operao protegida. Nome Para ser eficaz, o nome dever ser o mais significativo e expressivo possvel. O nome no precisa ser nico dentro de uma Classe. Porm, a combinao do nome, lista de parmetros e resultado de retorno, normalmente chamado de assinatura deve ser nico dentro da Classe. Lista de parmetros uma lista ordenada dos atributos que, juntos, definem, a entrada para uma operao, podendo esta ser opcional, ou seja, uma operao no precisa ter parmetros. Resultado-retorno O resultado-retorno a sada da operao. Uma observao vlida para o resultado-retorno que no obrigatrio o retorno proveniente das operaes, entretanto, vlido lembrar que para algumas linguagens obrigatrio expressar o no retorno como o caso do C++ onde usada a palavra reservada void. Propriedade O elemento de propriedades permite acrescentar praticamente qualquer informao adicional sobre a operao, que no se encaixe em um dos elementos predefinidos. Um uso como para as propriedades como uma descrio da implementao da operao, como vemos na sintaxe a seguir para declarao de uma operao:

definirDurao (nova_durao: int):void {a nova durao no pode causar sobreposio com outro evento planejado} Operaes no nvel de classe Operaes estticas, o retorno sempre igual, retorna o valor de atributos estticos da Classe. RELACIONAMENTOS AVANADOS Ttulo: Capturando regras sobre relacionamentos de objetos Motivao:... Para coordenar a interao entre recursos, preciso explicar como eles podem se comunicar. Para se comunicar, eles precisam estar cientes um do outro. Os objetos tambm precisam definir um meio para se comunicarem, eles precisam definir um tipo de relacionamento. Uma associao um relacionamento semntico entre dois elementos do modelo. Em um diagrama de Classes, uma associao define regras que se aplicam a relacionamentos entre os objetos definidos pelas classes participantes. Cada associao inclui as regras para estabelecer e manter a integridade dos relacionamentos, enquanto os relacionamentos so criados e usados pela aplicao. O Mesmo conceito pode ser refinado para levar em considerao objetos que sejam realmente montagens de outros objetos. Esse tipo de associao de montagem, chamado agregao, facilita bastante o uso de configuraes complexas de objetos. A agregao tambm pode ser refinada para modelar montagens onde as partes possuem uma associao mais restrita com a montagem. Nesse refinamento de agregao, chamado composio, as vidas das partes da montagem dependem totalmente de sua participao na montagem. Um relacionamento de dependncia no exige a comunicao direta. Nesse relacionamento, um objeto conta com o fato de que outro objeto existe e est realizando ou realizou sua tarefa. Por exemplo, uma transao comercial pode depender do sistema de segurana para garantir que nenhuma pessoa no autorizada poder acessar a transao comercial. A implementao desse relacionamento tratada no workflow, na tecnologia ou em outras opes de projeto na aplicao. A generalizao usada no contexto de herana. Um relacionamento de generalizao muito diferente de uma associao. De fato, a generalizao no exige qualquer uma das regras estabelecidas para associaes. Em vez disso, a generalizao define organizao de informaes sobre objetos que compartilham o mesmo significado semntico, masque variam em seus recursos individuais. Por exemplo, o termo carro refere-se a uma grande variedade de veculos. Para um fabricante de carros, importante diferenciar os carros de passeio, caminhonetes, caminhes, etc., baseado nos recursos que os diferem. Tipos de Associaes (ligaes) Associaes (e ligaes) assumem 3 formas diferentes:

Associao (agregao e composio); Dependncia; Generalizao.

Uma ligao um relacionamento entre dois objetos. Uma associao um relacionamento entre duas classes. Propsito de uma Associao Estabelecer o motivo pelo qual duas classes de objetos precisam saber uma a respeito da outra e as regras que controlam o relacionamento. Funo de uma Associao Um modo de identificar a associao de modo nico e significativo; O nmero de objetos que podem participar na associao; As restries sobre os objetos que tm permisso para participar associao; A funo que cada tipo de objeto desempenha quando participa associao; Um meio de identificar quais objetos podem obter acesso atravs associao; Informaes sobre a associao, como quando ela iniciou, os termos associao, quando ela terminou e seu status atual. Modelando

na na da da

A associao define um nico tipo de relacionamento, que pode ser estabelecido entre locais e eventos. Um relacionamento real chamado de ligao (link), uma associao uma regra e uma ligao um fato. Nome da associao O modo normal de nomear com verbo ou frase verbal.

Podendo ser indicado o sentido do relacionamento com uso do indicador direcional. Extremidade da associao Papeis; Especificador de interface; Visibilidade (obrigatrio); Multiplicidade (obrigatrio); Ordenao; Restries; Qualificador; Navegabilidade; Modificabilidade (chanteability); Papeis

Especificador de Interface [Nome_papel:Interface] Ex.: pea:Preo Visibilidade J comentada. Multiplicidade

Ordenao {ordered} Simplesmente indica que os elementos devem ser organizados no grupo.

Restries Uma restrio define uma reserva que precisa ser imposta sobre o elemento de modelagem para garantir a integridade durante a vida do sistema.

Qualificador Oferece um meio para ir diretamente ao objeto que deseja.

Navegabilidade Descreve a necessidade de um objeto acessar outro objeto navegando por uma ligao. A definio do atributo de navegabilidade da extremidade de uma associao determina se o objeto na outra extremidade da ligao pode acessar o objeto na extremidade navegvel da ligao.

Modificabilidade Modificadores existentes: Acrescentar; Alterar; Excluir; Mover. Ex.: {frozen} quando a ligao tiver sido estabelecida, ela no poder ser alterada ou movida; {addOnly} quando a aplicao s permitir que novas ligaes sejam criadas (sem excluso); Propsito de uma Agregao A agregao descreve um tipo especifico de associao, criado para nos ajudar a lidar com a complexidade. Em uma associao tpica, as classes so emparelhadas. Cada classe permanece independente da outra e nenhuma classe superior a outra. Elas simplesmente se comunicam. A agregao, por outro lado define um relacionamento hierrquico definitivo. Funo de uma Agregao Usada principalmente para definir e proteger a integridade de uma configurao de objetos; Define uma configurao, de modo que a coleo de objetos pode ser gerenciada como uma nica unidade, como se a coleo fosse um grande objeto; Define um foco de controle em uma direo na configurao, que oferece a interface para configurao. O objeto de controle, ento, propaga instrues aos objetos dentro da configurao para satisfazer a interface.

Os objetos so cientes uns dos outros, de modo que podem trabalhar juntos Protege a integridade da configurao; Funciona como uma nica unidade; Controla atravs de um objeto propaga para baixo.

Propsito de uma Composio usada para agregaes onde o tempo de vida do objeto membro depende do tempo de vida do agregado. O agregado no apenas tem controle sobre o comportamento do membro mas tambm tem controle sobre a criao e destruio do membro. Funo de uma Composio Os objetos so cientes uns dos outros, de modo que podem trabalhar juntos Protege a integridade da configurao; Funciona como uma nica unidade; Controla atravs de um objeto propaga para baixo. Uma parte pode ser membro de somente uma configurao; A parte no pode existir fora da configurao.

Diferena entre Agregao e Composio A composio usada para agregao em que o tempo de vida da pea depende do tempo de vida do objeto agregado. O agregado tem controle sobre a criao e destruio da pea. Resumidamente o objeto-membro no pode existir fora da montagem. Distinguindo Generalizao de Associao As associaes definem as regras para o modo como os objetos podem se relacionar entre si. A generalizao relacionam as classes umas s outras, onde cada classe contm um subconjunto das caractersticas necessrias para definir um tipo de objeto.

Casos de Uso Modelo de Casos de Uso O modelo de Casos de Uso foi proposto por I. Jacobson como um instrumento para descrio das intenes ou requisitos para um sistema computacional. A construo do Modelo de Casos de Uso corresponde a uma das fases iniciais de um projeto de software pois envolve a determinao dos usos que o sistema ter , ou seja, do que ele dever fornecer como servios. O modelo de Casos de Uso diferente da viso funcional utilizada no passado nas abordagens de projeto estruturado. Ao invs de focalizar as funes (atribuies tcnicas) do sistema, o modelo de Casos de Uso captura os usos ou aplicaes completas do sistema. Este modelo busca responder a questo: Que usos o sistema ter? ou Para que aplicaes o sistema sera empregado? Os modelos de Casos de Uso so descritos atravs 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, possvel decompor o diagrama em um conjunto de subdiagramas. Uma vez construdo 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 realizao dos casos de uso (que classes e objetos so necessrios, como e quando cada um atuara , etc). O modelo de Casos de Uso um instrumento eficiente para determinao e documentao dos servios a serem desempenhados pelo sistema. Ele tambm um bom meio para comunicao com os clientes no processo de definio dos requisitos do sistema. Diagramas de Casos de Uso Os casos de uso de um projeto de software so descritos na linguagem UML atravs de Diagramas de Casos de Uso. Estes diagramas utilizam como primitivas Atores, Casos de Uso e Relacionamentos. Como ocorre tambm com outros diagramas, pode-se ainda utilizar as primitivas Pacote e Nota nos diagramas de casos de uso. As subsees a seguir descrevem estas primitivas. Atores Atores so representaes de entidades externas mas que interagem com o sistema durante sua execuo. Basicamente, a interao de atores com o sistema se da atravs de comunicaes (troca de mensagens). As entidades externas representadas pelos atores podem ser : Pessoas: usurio, secreta ria, aluno, professor, administrador,etc. Dispositivos: impressora, ma quina ou outro equipamentos externo. Hardwares: placa de modem, placa de controle, etc. Software: sistema de banco de dados, aplicativos, etc.

E importante observar que atores representam, na verdade, papis desempenhados por pessoas, dispositivos ou outros softwares quando estiverem interagindo com o sistema. Por exemplo, um ator cujo identificador seja Aluno no representa um aluno especfico 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 vrios indivduos, equipamentos ou softwares. De forma anloga, uma entidade externa pode ser representada na forma de vrios atores. Isto ocorre quando a entidade tem mais de um papel (tipo de participao ou interao) no sistema. Por exemplo, o indivduo Joo da Silva poderia ser representado em um sistema na forma do ator Usurio, pois ele interage com o sistema nesta qualidade, e tambm na forma do ator Administrador, pois ele tambm interage com o sistema para este outro fim que a administrao do software. Atores so representados atravs de retngulos (notao genrica para classe) usando a simbologia padro da UML ou atravs de cones humanos. As duas notaes so sintaticamente equivalentes, porm 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 no coincide com a natureza do ator. E possvel, entretanto, atravs de mecanismos de extenso, criar grafismos especiais ou especializados na UML para indicar tipos de atores.

Observe que a notao usando retngulos exige a insero de um classificador para indicar a natureza daquilo que se esta representando. No caso de atores, deve-se incluir o classificador (ou esteretipo) <<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 discusses com os clientes. Procura-se neste estudo levantar as pessoas que sero beneficiadas e que usaro o sistema. Alm disso, deve-se levantar os dispositivos e softwares com os quais o sistema devera se comunicar. Para muitos projetos, pode no ser fcil levantar corretamente o conjunto de atores na primeira tentativa. O estudo dos casos de uso e dos relacionamentos com atores pode permitir refinar o conjunto de atores definidos. O estudo das classes do sistema, a ser feito na prxima fase, tambm ira contribuir para o refinamento do levantamento de atores. Embora a UML no imponha restries, costuma-se considerar determinados atores como atores implcitos. Desta forma estes atores no aparecem no diagrama de casos de uso embora eles estejam presentes e participem da execuo dos casos de uso. Os atores implcitos representam essencialmente dispositivos e softwares que so sempre usados e que no impem protocolos especiais de comunicao. Desta forma, a supresso deste

atores no traz nenhum efeito significativos sobre os modelos e simplifica as representaes. Os exemplos mais comuns de atores que se pode considerar como implcitos so : monitor de vdeo, teclado, mouse, alto-falante, microfone, unidade de disco e sistema operacional. Estas entidades sero atores legtimos mas cuja incluso no modelo de casos de uso no traz contribuio para a modelagem. Casos de Uso A descrio dos servios a serem oferecidos pelo sistema feita na UML discriminando-se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicao ou uso completo do software. O conceito de caso de uso no deve ser confundido com o de mdulo j que um caso de uso no um componente do sistema mas sim um de seus empregos possveis. Tambm no se deve confundir o conceito de caso de uso com o de funo que possui um escopo muito mais limitado, traduzindo frequentemente apenas um recurso ou utilidade do sistema. Um caso de uso muito mais abrangente, envolvendo todo um conjunto de transaes que juntas constituem um servio completo oferecido pelo sistema. A especificao das funcionalidades de um sistema na forma de casos de uso permite uma viso mais abrangente das aplicaes do sistema favorizando um levantamento mais completo e preciso de suas atribuies. 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 subsees seguintes. Relacionamentos entre Atores Como os atores so entidades externas, os relacionamentos entre eles sero relaes externas ao sistema. Embora estas relaes possam ser desprezadas, pois no fazem parte do sistema e nem so de conhecimento do sistema, possvel inclu-las no modelo de casos de uso. De certa forma, estas relaes descrevem parte do modelo de nego cios da empresa. As duas relaes mais comuns entre atores so a comunicao (ou associao) e a especializao (ou generalizao). Um relacionamento de comunicao indica que os dois atores, de forma uni ou bidirecional, realizam uma comunicao (troca de informao ou de mensagem) que possui um significado formal para o sistema modelado. No exemplo da figura I.2, o ator Aluno comunica-se com o ator Secretaria no sentido que transmitir uma Solicitao de Histo rico Escolar. Trata-se de uma comunicao explcita cuja ocorrncia deve ter alguma repercusso ou significado para o sistema. Um relacionamento de generalizao, por outro lado, representa uma relao conceitual entre atores indicando que um ator um caso especial de outro ator mais genrico. Esta relao indica que o ator especializado inclui todos os atributos do ator genrico e inclui ainda atributos adicionais. Como ilustra a figura I.2, o ator Administrador um ator especializado do ator Usurio. Isto significa que o Administrador um Usurio com atributos ou caractersticas extras. De certa forma, o ator especializado estende o ator genrico.

Relacionamentos entre Atores e Casos de Uso O relacionamento entre um ator e um caso de uso expressa sempre uma comunicao entre eles, pois o ator sendo uma entidade externa no poderia possuir qualquer relacionamento estrutural com o sistema computacional. A notao UML para este tipo de relacionamento um segmento de reta ligando ator e caso de uso, como ilustrado na figura I.3. Em diagramas mais complexos pode-se utilizar cadeias de segmentos de retas para se evitar cruzamentos. Como atores podem ter vrios propsitos, no que diz respeito a suas interaes com o sistema, podem existir mais de um relacionamento de um ator com diferentes casos de usos. De forma anloga, um mesmo caso de uso pode envolver a participao de mais de um ator. A figura I.3 ilustra estas situaes. O caso de uso Emitir Histo rico Escolar envolve a participao de dois atores : Secretaria e Impressora. O ator Secretaria participa em dois casos de uso: Emitir Histo rico e Registrar Novo Aluno.

A utilizao de setas nas relaes entre atores e casos de uso pode ter duas interpretaes distintas. Na primeira, utilizam-se setas para indicar qual ator ativa o caso de uso. Ativao neste caso significa, quem lana ou inicia a execuo do caso de uso. Para sistemas interativos, frequentemente o ator Usurio quem ativa o caso de uso. Na situao mais comum, cada caso de uso s teria um ator contendo uma seta em seu relacionamento de comunicao. E possvel, entretanto, haver mais de um ator ativador para um mesmo caso de uso significando que um deles ativaria este caso de uso. O exemplo na figura I.3 aplica esta interpretao das setas. A segunda interpretao para as setas a indicao do sentido do fluxo de dados nas comunicaes. Neste caso todas as relaes entre atores e casos de uso teriam setas em uma ou nas duas extremidades descrevendo o sentido da comunicao com cada ator. As duas interpretaes so possveis mas deve-se optar por uma delas em cada projeto e indicar explicitamente a interpretao adotada.

Relacionamentos entre Casos de Uso Ao contra rio do relacionamento entre ator e caso de uso, as relaes entre casos de uso nunca sero do tipo comunicao. Isto ocorre porque casos de uso so aplicaes completas do sistema e, por consequ e ncia, no existe sentido em fazer-se comunicar dois usos do sistema. Todas as relaes entre casos de uso sero sempre estruturais. Existem tre s tipos de relaes entre casos de uso (incluso, extenso e generalizao) conforme descritos a seguir. Relacionamento de Incluso Um relacionamento de incluso uma relao estrutural atravs da qual um caso de uso insere em seu interior um outro caso de uso. O caso de uso includo (subcaso de uso) no representa um servio completo do sistema mas uma poro de um servio. Isoladamente, um subcaso de uso no teria sentido. Ele sera sempre um integrante de um caso de uso maior e completo. O relacionamento de incluso se aplica a duas situaes principais. A primeira aplicao da Incluso para o detalhamento de casos de uso atravs de decomposio. Nesta situao, extraem-se partes significativas de um caso de uso criando-se subcasos de uso ligados ao caso de uso maior atravs de relaes de incluso. Embora raro, possvel ainda decompor subcasos de uso em outros subcasos de uso. Uma segunda aplicao do relacionamento de incluso a de colocar em evidncia partes comuns a dois ou mais casos de uso. Nesta situao o subcaso de uso includo por mais de um caso de uso

maior. A figura I.4 ilustra estas duas situaes. Relacionamento de Extenso Um relacionamento de extenso uma relao estrutural entre dois casos de uso atravs da qual um caso de uso maior estendido por um caso de uso menor. A extenso significa que o caso de uso que estende inclui

servios especiais em um caso de uso maior. A definio de um relacionamento de extenso inclui a especificao de uma condio de extenso. Esta condio habilita a extenso, ou seja, indica quando aplicar o relacionamento. A notao para o relacionamento de extenso ilustrada na figura I.5.

A diferena principal entre os relacionamentos de incluso e extenso o cara ter de excepcionalidade da extenso. Extenses so usadas para modelar casos especiais e de exceo que ocorrem somente em certas situaes (dado pela condio). Desta forma, para a maioria das ocorrncias do caso de uso estendido, a extenso no se aplicara . Relacionamento de Generalizao Um relacionamento de generalizao uma relao estrutural entre um caso de uso mais geral e um caso de uso mais especfico. O caso de uso mais geral representa o caso genrico cujo servio se aplica a vrias situaes. O caso de uso mais especfico representa a aplicao do caso uso mais geral em uma situao particular incluindo elementos adicionais ou estendendo este caso. Visto no outro sentido, o caso de uso mais geral uma generalizao (abstrao) do ou dos casos de uso mais especficos. Neste sentido, o caso de uso geral, representa as partes comuns de casos de uso especializados. A notao UML para a generalizao envolve a ligao dos dois casos de uso atravs de um segmento de reta e a colocao de um tringulo na extremidade do caso de uso mais geral. A figura I.6 apresenta um exemplo de relacionamento de generalizao.

No exemplo da figura I.6, tem-se um caso de uso mais geral, chamado Emitir Histo rico Escolar, que permite a secretaria imprimir histo ricos de alunos. Quando o aluno conclui na totalidade o curso, ele pode solicitar um histo rico de concluso. Este histo rico semelhante ao histo rico normal mas mais detalhado incluindo informaes adicionais. O caso de uso Emitir Histo rico Escolar de Concluso portanto semelhante ao caso de uso Emitir Histo rico Escolar mas com alguns elementos adicionais. Pode-se, como feito no

exemplo, estabelecer uma relao de especializao entre os dois casos de uso. A relao estrutural definida por um relacionamento de generalizao implica a incorporao (herana) dentro do caso de uso especializado de todo o servio especificado pelo caso de uso geral, incluindo, adaptando ou excluindo alguns servios oferecidos pelo caso de uso geral. O relacionamento de generalizao no pode ser confundido com os de incluso e extenso pois a generalizao se aplica, na maior parte dos casos, a compartilhamentos de maior dimenso. A incluso e extenso envolvem partes menores de casos de usos. A natureza da generalizao tambm distinta pois trata-se de especificar modelos (casos de uso) genricos aplica veis a diferentes situaes. A incluso e a extenso apenas pem em evidncia partes de casos de uso maiores. Decomposio de Diagramas de Casos de Uso Um projeto de software, normalmente, conter um nico Diagrama de Casos de Uso descrevendo o conjunto de servios oferecidos pelo sistema. Para sistemas maiores ou mais complexos, entretanto, possvel a construo de vrios diagramas de casos de uso elaborados a partir da decomposio de um diagrama principal. A decomposio de um diagrama de casos de uso pode ser feita em UML utilizando o conceito de Pacote (package). Um pacote um encapsulador que no possui uma semntica especfica dentro dos projetos. Ele usado essencialmente para separar ou agrupar elementos do projeto sem criar necessariamente com isso algum vnculo 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 expandi-lo em um novo diagrama. Pode-se construir uma hierarquia com vrios nveis de decomposio conforme a dimenso do sistema e o nmero 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 dependncia entre pacotes. As dependncias devem ser explicitamente definidas utilizando como notao um segmento de reta tracejado com uma seta no sentido do pacote que depende para o pacote que contm as dependncias. A figura I.7 ilustra a notao utilizada para pacotes e dependncias.

No existe uma norma para separao 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 emisso

de relato 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. Exemplo Para ilustrar a aplicao do conceito de caso de uso, desenvolve-se nesta seo um exemplo de modelagem para um sistema de controle acadmico. Embora, o desenvolvimento completo de um modelo de casos de uso possa envolver vrias iteraes de refinamento, para fins didticos o exemplo deste seo apresentara a modelagem atravs de 4 fases. Fase 1 : Levantamento dos Atores O sistema de controle acadmico considerado neste exemplo sera utilizado na secretaria de um determinado curso. No que diz respeito aos indivduos envolvidos, somente o pessoal da secretaria ter acesso ao sistema. Entre as pessoas que atuam na secretaria e poderiam utilizar o sistema esto o chefe da secretaria, a secreta ria, alguns professores e alguns estagia rios. Na verdade, apesar de se tratarem de indivduos diferentes, quando estiverem utilizando o sistema todos assumiro o mesmo papel, ou seja, todos atuaro na forma de um ator abstrato que pode ser denominado Secretaria. Preliminarmente, supe-se que alguns documentos devero ser impressos pelo sistema, o que sugere a criao de um ator denominado Impressora com o qual o sistema ira interagir para a impresso de documentos (histo rico escolar, dia rio de classe, etc). O ator impressora poderia ser considerado um ator implcito mas pode ser ilustrativo faze -lo aparecer explicitamente no modelo. Como o volume de informaes (alunos, professores, disciplinas, etc) pode ser grande optou-se pelo uso de um Sistema Gerenciador de Banco de Dados para armazenamento dos dados acadmicos. Como se trata de um sistema computacional independente com o qual o sistema de controle acadmico ira interagir, ele deve ser considerado tambm como um ator. Neste exemplo, este ator sera denominado SGBD. Portanto, os atores que foram inicialmente levantados so:

Na pra tica, nem sempre possvel determinar todos os atores e definilos corretamente na primeira tentativa. Se for considerada uma abordagem de projeto por refinamentos sucessivos, a lista de atores poderia ser melhorada, assim como a definio deste atores, a medida que o projeto avance quando mais informaes estiverem disponveis. Fase 2 : Levantamento dos Casos de Uso Principais Nesta fase busca-se definir a lista dos grandes servios que o sistema devera oferecer. O levantamento dos casos de uso corresponde a uma ana lise

de requisitos e deve ser desenvolvido a partir de informaes coletadas dos clientes. Atravs de questiona rios e reunies com os clientes procura-se definir quais so as aplicaes ou usos desejados para o sistema a ser desenvolvido. Para o sistema de controle acadmico considera-se que os clientes (usurios, professores e administrao da escola) desejam que o sistema oferea os seguintes servios : - possibilidade de cadastramento de todos os alunos matriculados no curso. Isto implica um servio para incluso de novos alunos e para manuteno da base de dados dos alunos. Este uso do sistema sera representado pelo caso de uso Cadastrar Aluno. - possibilidade de cadastramento de todos os professores que ministram disciplinas no curso. Isto implica um servio para incluso de novos professores e para manuteno da base de dados de professores. Este uso do sistema sera representado pelo caso de uso Cadastrar Professor. - possibilidade de registro das disciplinas oferecidas no curso incluindo o registro de novas disciplinas e a manuteno da base de dados de disciplinas. Este servio ou uso do sistema sera representado pelo caso de uso Cadastrar Disciplina. - possibilidade de registro da matrcula de alunos em disciplinas a cada semestre. Este servio sera representado pelo caso de uso Registrar Matrcula. - possibilidade de emisso da confirmao de matrcula para cada aluno contendo a lista de disciplinas nas quais um aluno se matriculou para aquele semestre. Este servio sera representado pelo caso de uso Emitir Confirmao de Matrcula. - possibilidade de emisso do dia rio de classe para cada disciplina contendo a lista de alunos matriculados naquele semestre. Este servio sera representado pelo caso de uso Emitir Dia rio de Classe. - possibilidade de lanamento das notas obtidas pelos alunos em cada disciplina ao final de cada semestre. Este servio sera representado pelo caso de uso Registrar Nota. - possibilidade de emisso do histo rico escolar para cada aluno contendo a lista de disciplinas cursadas e respectivas notas. Este servio sera representado pelo caso de uso Emitir Histo rico Escolar. O conjunto de casos de uso levantados representa os servios ou usos esperado pelos clientes que utilizaro o sistema. Assim como para os atores, nem sempre possvel 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 alteraes. A figura I.9 ilustra os casos de uso definidos para o sistema acadmico.

Fase 3 : Definio dos Relacionamentos Nesta fase so estabelecidos os relacionamentos de comunicao 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 I.10. Neste diagrama de casos de uso, adotou-se o uso de setas nas relaes para indicar qual ator responsvel pela ativao dos casos de uso. Fase 4 : Detalhamento dos Casos de Uso Nesta fase feito um detalhamento dos casos de uso atravs de decomposies ou especializaes. O grau de detalhamento necessrio um aspecto subjetivo. Cabe ao projetista julgar qual o bom nvel de detalhamento para cada projeto. No se deve exagerar nas decomposies sob o risco de se estar influenciando ou direcionando o processo de projeto. Deve-se lembrar que os diagramas de casos de uso so especificaes do que o sistema deve fazer e no de como ele devera realizar os servios. Como abordagem geral para esta fase existem as seguintes sugestes: Procure estimar a dimenso 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 atravs de relaes de incluso. Para o sistema de controle acadmico, considerou-se que os trs casos de uso para cadastramento (aluno, professores e disciplinas) tem uma dimenso maior e incluem servios internos (incluso, consulta, alterao e excluso) que podem ser destacados. Assim, optou-se por decompor cada um destes casos de uso em quatro subcasos de uso. Compare par a par os casos de uso tentando identificar partes comuns nos servios associados a cada caso de uso. Quando dois ou mais casos de uso possuem parte em comum de dimenso significativa, esta parte em comum pode ser colocada em evidncia atravs de um subcaso de uso. Para o sistema de controle acadmico, foi decidido que o usurio devera se identificar atravs de nome e senha para ter acesso aos servios de cadastramento e registro de matrcula e notas. Assim, todos os casos de uso associados teriam uma fase inicial idntica em seus processos que corresponderia a realizao de login. Esta parte comum pode ser indicada atravs de um subcaso de uso comum. Quando dois ou mais casos de uso tiverem grande parte de seus servios semelhante, verifique a possibilidade de definio de um caso de uso geral que cubra a parte comum deste casos de uso. Especifique, ento, um relacionamento de generalizao entre o caso de uso geral e os casos de uso especializados.

A figura I.11 apresenta o diagrama de casos de uso final para o sistema de controle acadmico. Na verdade, este diagrama poderia ser melhorado e detalhado a partir das primeiras iteraes do projeto. A medida que o projeto avance e a forma de realizao dos casos de uso seja definida, pode-se verificar a necessidade de alterao ou adaptao do diagrama de casos de uso.

Concluso O modelo de casos de uso uma ferramenta til na descrio dos requisitos funcionais de um sistema computacional. Ele permite especificar o conjunto de funcionalidades ou servios que um software deve oferecer e as relaes do sistema com entidades externa (atores) necessrias para a realizao destes servios. A notao UML para diagramas de casos de uso em grande parte intuitiva permitindo que os modelos gerados possam ser apresentados aos clientes para discusses e revises. Deve-se sempre observar que o modelo de casos de uso diferente da viso funcional no sentido que ele no apresenta encadeamentos de funes (por consequncia, no descreve processos) e se limita a uma viso macroscpica dos servios do sistema sem induzir a forma de realizao (projeto) do software. O modelo de casos de uso oferece uma viso mais abstrata das funcionalidades do sistema favorizando um trabalho de especificao mais abrangente. Por fim, o modelo de casos de uso pode tambm ser til como ferramenta para planejamento do desenvolvimento de sistemas computacionais (estimativas por caso de uso) e como base para o desenvolvimento de projetos de software (projeto baseado em casos de uso).

Bibliografia e apoio literrio Apoio: http://imasters.uol.com.br/artigo/6389 Bibliografia: http://www.uml.org/ BOOCH Grady, RUMBAUGH James, JACOBSON Ivar UML Guia do Usurio 2 Edio.