Projeto de Software usando UML

Capítulo I : Casos de Uso1 Modelo de Casos de UsoO modelo de Casos de Uso foi proposto por I. Jacobson como um instrumento paradescrição das intenções ou requisitos para um sistema computacional. A construção do Modelode Casos de Uso corresponde a uma das fases iniciais de um projeto de software pois envolvea determinação dos usos que o sistema terá, ou seja, do que ele deverá fornecer comoserviços.O modelo de Casos de Uso é diferente da visão funcional utilizada no passado nasabordagens de projeto estrututado. Ao invés de focalizar as funções (atribuições técnicas) dosistema, o modelo de Casos de Uso captura os usos ou aplicações completas do sistema. Estemodelo busca responder a questão: Que usos o sistema terá? ou Para que aplicações osistema será empregado?Os modelos de Casos de Uso são descritos através de Diagramas de Casos de Uso naUML. 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 desubdiagramas.Uma vez construído o modelo de Casos de Uso, o restante do projeto pode ser guiadobaseando-se neste modelo. Dito de outra forma, a partir do modelo de Casos de Uso, orestante do projeto irá se preocupar com a forma de realização dos casos de uso (que classese objetos são necessários, como e quando cada um atuará, etc).Omodelo de Casos de Uso é um instrumento eficiente para determinação edocumentação dos serviços a serem desempenhados pelo sistema. Ele é também um bommeio para comunicação com os clientes no processo de definição dos requisitos do sistema.2 Diagramas de Casos de UsoOs casos de uso de um projeto de software são descritos na linguagem UML através deDiagramas de Casos de Uso. Estes diagramas utilizam como primitivas Atores, Casos de Usoe Relacionamentos. Como ocorre também com outros diagramas, pode-se ainda utilizar asprimitivas Pacote e Nota nos diagramas de casos de uso. As subseções a seguir descrevemestas primitivas.2.1 AtoresAtores são representações de entidades externas mas que interagem com o sistemadurante sua execução. Basicamente, a interação de atores com o sistema se dá através decomunicações (troca de mensagens). As entidades externas representadas pelos atorespodem ser :Pessoas: usuário, secretária, aluno, professor, administrador,etc.Dispositivos: impressora, máquina ou outro equipamentos externo.Hardwares: placa de modem, placa de controle, etc.Software: sistema de banco de dados, aplicativos, etc.Pág.: 3É importante observar que atores representam, na verdade, papéis desempenhados porpessoas, dispositivos ou outros softwares quando estiverem interagindo com o sistema. Porexemplo, um ator cujo identificador seja Aluno não representa um aluno específico mas sim umaluno qualquer, ou seja, uma pessoa qualquer que esteja interagindo com o sistema naqualidade 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 representadana forma de vários atores. Isto ocorre quando a entidade tem mais de um papel (tipo departicipação ou interação) no sistema. Por exemplo, o indivíduo João da Silva poderia serrepresentado em um sistema na forma do ator Usuário, pois ele interage com o sistema nestaqualidade, e também na forma do ator Administrador, pois ele também interage com o sistemapara 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 asimbologia padrão da UML ou através de ícones humanos. As duas notações sãosintaticamente equivalentes, porém a segunda é seguramente mais intuitiva. A desvantagemdo uso de ícones humanos ocorre quando o ator representa equipamentos, dispositivos dehardware ou outros softwares. Neste caso, a figura humana não coincide com a natureza doator. É possível, entretanto, através de mecanismos de extensão, criar grafismos especiais ouespecializados na UML para indicar tipos de atores.AdministradorUsuárioSecretária ImpressoraFigura I.1 – Exemplos de AtoresObserve que a notação usando retângulos exige a inserção de um classificador paraindicar a natureza daquilo que se está representando. No caso de atores, deve-se incluir oclassificador (ou estereótipo) antes do nome do ator. Quando se utiliza o íconehumano, basta indicar o nome do ator abaixo do ícone.O levantamento dos atores que interagem com um certo sistema depende de um trabalhode estudo que envolve discussões com os clientes. Procura-se neste estudo levantar aspessoas que serão beneficiadas e que usarão o sistema. Além disso, deve-se levantar osdispositivos e softwares com os quais o sistema deverá se comunicar. Para muitos projetos,pode não ser fácil levantar corretamente o conjunto de atores na primeira tentativa. O estudodos casos de uso e dos relacionamentos com atores pode permitir refinar o conjunto de atoresdefinidos. O estudo das classes do sistema, a ser feito na próxima fase, também irá contribuirpara o refinamento do levantamento de atores.Embora a UML não imponha restrições, costuma-se considerar determinados atorescomo atores implícitos. Desta forma estes atores não aparecem no diagrama de casos de usoembora eles estejam presentes e participem da execução dos casos de uso. Os atoresimplícitos representam essencialmente dispositivos e softwares que são sempre usados e quenão impõem protocolos especiais de comunicação. Desta forma, a supressão deste atores nãotraz nenhum efeito significativos sobre os modelos e simplifica as representações. Os exemplosmais 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ãoatores legítimos mas cuja inclusão no modelo de casos de uso não traz contribuição para amodelagem.Pág.: 4