A constru¸c˜ao de modelos para captura e representa¸c˜ao dos requisitos ao inv´es das listas de requisitos facilita a leitura, simplifica a realidade e o entendimento da problem´atica inicial que originar´a o novo sistema (Zowghi & Coulin, 2005). A forma de conce¸c˜ao dos modelos influencia o desenvolvimento da solu¸c˜ao, neste sentido a linguagem UML (Unified Modeling Language) destaca-se como uma forma de representar o sistema futuro utilizando uma abor- dagem orientada a objetos atendendo `a m´axima de que uma imagem vale mais do que mil palavras (Booch et al., 1998).
3.2.1 Introdu¸c˜ao `a linguagem UML
A Linguagem UML recorre a uma nota¸c˜ao standard e a um conjunto de regras que permi- tem especificar, visualizar, construir e documentar sistemas orientados a objetos (Rumbaugh et al., 1999). Assim, para a constru¸c˜ao de modelos assentes na linguagem UML existe um conjunto de fases (Booch et al., 1998):
1 An´alise de Requisitos Fase onde se procede ao levantamento e identifica¸c˜ao das necessi- dades e especificidades dos futuros utilizadores do sistema, sendo representadas atrav´es de casos de uso.
2 An´alise de Sistema Fase onde se inicia o entendimento do problema atrav´es do desen- volvimento dos primeiros modelos abstratos (classes e objetos).
3 Design Fase em que se obt´em as solu¸c˜oes t´ecnicas derivadas do modelo concebido. 4 Programa¸c˜ao Fase de programa¸c˜ao e implementa¸c˜ao dos modelos desenvolvidos. 5 Testes Fase de realiza¸c˜ao de diversos testes.
O entendimento das diversas fases para a constru¸c˜ao dos modelos assentes em UML cria a necessidade de conhecer os diagramas em UML e a respetiva nota¸c˜ao utilizada. Assim seguidamente apresentam-se os diversos diagramas.
3.2.2 Diagramas em UML
Um diagrama, descrito por Booch et al. (1998), ”´e a representa¸c˜ao gr´afica de um con- junto de elementos que descrevem o sistema de diversas perspetivas”. Existem nove tipos de diagramas, segundo o mesmo autor: diagramas de casos de uso, diagramas de classes, diagra- mas de objetos, diagramas de intera¸c˜ao (sequˆencia e colabora¸c˜ao), diagramas de atividades, diagramas de estados, diagramas de componentes e diagramas de execu¸c˜ao.
Diagramas de Casos de Uso Servem para mostrar as intera¸c˜oes dos atores com o sistema, descrevem as v´arias a¸c˜oes (casos de uso) dispon´ıveis e delimitam a fronteira do sistema. Diagramas de Classes Descrevem a estrutura est´atica das classes que s˜ao utilizadas no sistema. S˜ao constitu´ıdos por um conjunto de classes, interfaces, colabora¸c˜oes e rela¸c˜oes. Diagramas de Objetos Ilustram casos concretos do diagrama de classes.
Diagramas de intera¸c˜ao (sequˆencia e colabora¸c˜ao) Mostram o comportamento dos ob- jetos dentro de um caso de uso.
Diagrama de atividades Utilizados para descrever cada um dos casos de uso, real¸cando o encadeamento das atividades realizadas por cada um dos objetos do sistema, numa ´
otica de fluxo de trabalho.
Diagrama de estados Servem para descrever as altera¸c˜oes nos valores dos atributos dos objetos em resultado da ocorrˆencia de certos eventos.
Diagrama de componentes Mostram a organiza¸c˜ao e dependˆencias dos v´arios componen- tes.
Diagrama de execu¸c˜ao permitem descrever a arquitetura do equipamento inform´atico em termos de hardware, representando ainda a distribui¸c˜ao dos componentes da aplica¸c˜ao pelos elementos da arquitetura.
Neste trabalho ser˜ao usados os diagramas de casos de uso, classes e sequˆencias. Assim, iremos estudar pormenorizadamente a sua implementa¸c˜ao seguidamente.
3.2.2.1 Diagramas de Casos de Uso
Os diagramas de casos de uso permitem representar os requisitos funcionais de um sistema e s˜ao constitu´ıdos por atores, casos de uso e pelas rela¸c˜oes entre ambos (Booch et al., 1998). Os atores s˜ao elementos externos que interagem com o sistema de forma ativa (evento de input ) ou passiva (evento de output ), podendo ser humano ou sistemas inform´aticos (Booch et al., 1998). Um ator ´e representado com o ´ıcone de um indiv´ıduo (Figura 3.1 a).
O caso de uso ´e um conjunto de a¸c˜oes que um ou mais atores realizam num sistema de modo a obterem determinado resultado (Booch et al., 1998), isto ´e, descreve o que o que o sistema faz. A sua representa¸c˜ao ´e feita atrav´es de uma oval com a inscri¸c˜ao de a¸c˜ao (Figura 3.1 b). A a¸c˜ao deve ser escrita com um verbo no infinitivo, como por exemplo ”Criar Conta”(Pereira, 2008).
As rela¸c˜oes s˜ao a forma como o ator interage com os casos de uso (Figura 3.1 c). As rela¸c˜oes mais comuns s˜ao intituladas de associa¸c˜oes, mas existem outros tipos de liga¸c˜oes como dependˆencias e generaliza¸c˜ao (Booch et al., 1998). As dependˆencias podem dividir- se em uses ou extends. A uses aplica-se quando um caso de uso ´e executado e o que est´a dependente dele fica obrigado a ser executado. A extends utiliza-se quando ´e necess´ario retratar num segundo caso de uso um comportamento opcional. A generaliza¸c˜ao aplica-se quando se quer retratar num caso de uso um caso particular de um outro caso de uso. Assim, existe uma heran¸ca de propriedades, isto ´e, o caso de uso filho herda os comportamentos do caso de uso pai.
Figura 3.1: Nota¸c˜ao UML: a) ator, b) caso de uso e c) rela¸c˜oes
Por forma a construir um diagrama de casos de uso para modelizar os requisitos do sistema, pode seguir-se um conjunto de passos sequenciais, nomeadamente, identifica¸c˜ao e descri¸c˜ao dos atores, identifica¸c˜ao e organiza¸c˜ao dos casos de uso e elabora¸c˜ao do diagrama de casos de uso. No primeiro passo ´e definido o ˆambito do sistema, identificando e descrevendo os atores atrav´es de uma breve descri¸c˜ao textual. No segundo passo s˜ao definidos os comportamentos requeridos por parte do sistema para cada ator. No ´ultimo passo ´e especificada num esquema gr´afico a rela¸c˜ao entre atores e casos de uso atrav´es dos diferentes tipos de rela¸c˜oes.
3.2.2.2 Diagrama de Classes
Os diagramas de classes permitem visualizar e especificar a vis˜ao est´atica do sistema. Para isso, recorrem ao uso de abstra¸c˜oes como classes e rela¸c˜oes (Booch et al., 1998).
A classe ´e composta por um conjunto de objetos semelhantes entre si com as mesmas propriedades (atributos), comportamentos (opera¸c˜oes), rela¸c˜oes e identidade (Booch et al., 1998). Os objetos s˜ao instˆancias de uma classe e estas s˜ao diferentes entre si, pois possuem um conjunto de valores d´ıspares para os mesmos atributos.
A nota¸c˜ao da classe em UML (Figura 3.2) ´e a divis˜ao de um retˆangulo dividido em trˆes partes, contendo o nome da classe, atributo e opera¸c˜ao (opcional).
O nome da classe deve iniciar-se por mai´uscula, estar escrito no singular, ser curto e simples, sendo distintivo das outras classes. O atributo deve ser uma ´unica palavra, em que a primeira palavra deve ser escrita em letra min´uscula e a primeira letra das seguintes palavras em letra mai´uscula (por exemplo, dataNascimento). O tipo de atributo pode colocar-se opcionalmente a seguir a dois pontos ap´os a identifica¸c˜ao do atributo.
A utiliza¸c˜ao da opera¸c˜ao ´e opcional e quando usada serve para especificar comportamen- tos requisitados a um objeto da classe.
As rela¸c˜oes permitem a liga¸c˜ao entre objetos das diferentes classes e podem ser de v´arios tipos: associa¸c˜ao, agrega¸c˜ao, generaliza¸c˜ao e dependˆencia (Booch et al., 1998). Neste estudo s˜ao aplicadas as rela¸c˜oes de associa¸c˜ao e generaliza¸c˜ao detalhadas de seguida.
A rela¸c˜ao de associa¸c˜ao permite a liga¸c˜ao entre as classes envolvidas, devendo ser espe- cificados a multiplicidade e um nome que defina a sua natureza (Booch et al., 1998). A multiplicidade identifica o n´umero de instˆancias de uma classe que est˜ao relacionadas a uma ´
unica instˆancia da outra classe participante (Booch et al., 1998). A multiplicidade, expressa em n´umeros e/ou s´ımbolos, est´a presente nos extremos da rela¸c˜ao de associa¸c˜ao junto da linha da rela¸c˜ao e pr´oximo da classe correspondente. Na Figura 3.3, apresenta-se a rela¸c˜ao de associa¸c˜ao e a nota¸c˜ao para os v´arios tipos de multiplicidade.
Figura 3.3: Nota¸c˜ao das v´arias formas de multiplicidade
Existem diferentes tipos de rela¸c˜ao de associa¸c˜ao, como a associa¸c˜ao un´aria, bin´aria, exclusiva ou classes associativas. Neste estudo somente s˜ao utilizadas as rela¸c˜oes de associa¸c˜ao bin´aria dado que ´e a mais usualmente aplicada nos diagramas de classes, representando a liga¸c˜ao entre duas classes.
A rela¸c˜ao de generaliza¸c˜ao ocorre entre uma superclasse e uma ou mais classe que derivam de si pr´opria (subclasses), havendo uma organiza¸c˜ao de acordo com as semelhan¸cas e dife- ren¸cas. A superclasse tem atributos comuns com cada subclasse, no entanto cada subclasse acrescenta atributos espec´ıficos.
3.2.2.3 Diagrama de Sequˆencia
Segundo Booch et al. (1998), os diagramas de sequˆencia apresentam a ordem cronol´ogica das diversas intera¸c˜oes (mensagens) entre os objetos. Estes diagramas podem servir diversos prop´ositos dependente da fase do desenvolvimento do sistema. Numa fase inicial podem ser aplicados para documentar os casos de uso e numa fase mais avan¸cada do desenvolvimento, servem para representar as intera¸c˜oes entre objetos.
Para representar este tipo de diagrama colocam-se os objetos alinhados horizontalmente com a aplica¸c˜ao de uma linha vertical em todos eles que representa a linha de vida do objeto. Os objetos s˜ao representados atrav´es de um retˆangulo e caso seja um ator externo ao sistema representa-se com uma figura humana. Posteriormente, representam-se as v´arias intera¸c˜oes atrav´es de setas horizontais que apontam no sentido das linhas de vida dos objetos envolvidos e que s˜ao orientadas do emissor para o recetor das mensagens. Por forma a representar atrasos na transmiss˜ao das mensagens aplicam-se setas obl´ıquas. Um objeto pode tamb´em transmitir
uma mensagem para si pr´oprio. As intera¸c˜oes entre os objetos decorrem durante um per´ıodo de tempo e s˜ao representadas atrav´es de bandas retangulares colocadas sobre a linha de vida. A leitura das mensagens deve ser feita de cima para baixo e segundo a orienta¸c˜ao da seta.