Engenharia de Software Orientada a Objetos - OOSE Método de Jacobson

Transcrição

1 Universidade Federal de Goiás Instituto de Informática Ciência da Computação Engenharia de Software Orientada a Objetos - OOSE Método de Jacobson Projeto de Software Amanda Lira Gomes Lucas Balbino de Melo Ferreira Mycke Richard Guntijo Renato Gomes Borges Júnior 1. Introdução Com o surgimento da orientação a objetos, viu-se necessário criar métodos eficazes

2 para modelar estes novos sistemas. Cada método possui suas próprias terminologias, bem como a descrição do processo e a notação utilizada. Neste trabalho descrevemos o método OOSE (Object-Oriented Software Engineering - Engenharia de Software Orientada a Objeto), desenvolvido por Ivar Jacobson em 1992, que se caracteriza principalmente por utilizar casos de uso para descrever o sistema, também descrita em [2] como uma abordagem orientada a cenários. A metodologia de projeto orientado a objeto OOSE é a primeira a utilizar o conceito de Casos de Uso para definir os paradigmas do projeto de Software. Ivar Jacobson, nascido em 2 de Setembro de 1939, é um cientista da computação sueco que teve se formou Mestre em engenharia eletrônica no Chalmers Institute of Technology de Gotemburgo (em 1962) e PhD no Royal Institute of Technology de Estocolmo (já em 1985). Ele teve fundamental função no desenvolvimento da UML (Unified Modelign Language), junto com Grady Booch e James Rumbaugh, além do RUP (Rational Unified Process - Processo Unificado Racional). Para implementar a metodologia OOSE, a ferramenta Objectory foi criada pela equipe da Objectory AB para implementar a metodologia OOSE. Esta foi a pioneira, porém após o grande sucesso, outras ferramentas que suportavam OOSE surgiram [7]. A Objectory AB foi fundida com a Rational e com isso a notação, metodologia e ferramentas da OOSE foram substituídas pelas usadas pela Rational. Com o desenvolvimento da UML e da metodologia RUP, o OOSE foi se tornando obsoleta, pois o RUP já havia integrado os principais conceitos [9]. Na seção 2 explicamos os processos obtidos pela divisão realizada pelo método e como eles interagem entre si durante o desenvolvimento do projeto. A seção 3 ilustra os principais diagramas usados pelo método de Jacobson e como eles são aplicados na modelagem do sistema. A seção 4 descreve as principais heuristicas e a seção 5 mostra um estudo de caso realizado aplicando o modelo estudado. 2. Processo de funcionamento O desenvolvimento do projeto se divide em 3 processos que podem ser iterados e sobrepostos: análise, construção e teste. No processo de análise está incluído a análise de requisitos e a de robustez. Como a base desse modelo são os requisitos do cliente, ou do usuário final, é extremamente importante o entendimento (por parte do analista) dessas exigências. Para isso, faz-se uso do modelo de Casos de Uso ( Use Cases ) com as descrições de interface e o modelo dos objetos do domínio em questão. O modelo Use Case é basicamente composto pelos atores, que constituem a parte externa do sistema e são a principal ferramenta pra se encontrar as funcionalidades necessárias (podem executar uma ou mais tarefas), e a interação, onde os atores conseguem se comunicar com alguma funcionalidade interna do sistema. Após ter desenvolvido o modelo de requisitos, e o mesmo ter sido aprovado pelo cliente, pode-se começar a pensar na criação e estruturação do sistema. Como o

3 modelo gerado é totalmente orientado a aplicação, cria-se então um modelo Conceitual de configuração do sistema. Seu objetivo é encontrar a estrutura e robustez necessária no sistema, criando uma base para a sua futura construção. A estrutura geral do processo de análise é mostrada na figura 1. Figura 1. Etapa de Análise. Retirado de [6]. Já na construção, que é composta pelo desenho e implementação, há o refinamento e a formalização do modelo de análise, onde é levado em conta as possíveis consequências do ambiente de implementação. No modelo de desenho é definido explicitamente as interfaces dos objetos e também a semântica das operações. Nele também são atribuídas decisões em relação a base de dados, linguagem de programação, etc. Depois de identificar a arquitetura do sistema, é necessário descrever como os packages (onde os objetos estão agrupados) e os design objects irão se comunicar. Para cada caso de uso, deve ser desenhado um diagrama de interação (explicado em detalhes na seção 3), onde será descrito como o caso de uso é feito através da comunicação entre os packages. Os diagramas de interação obtidos podem ser utilizados em um nível intermediário de desenvolvimento, antes da implementação. Como eles tem uma descrição mais simplificada, aumentam a compreensão dos design objects ou até de um package, já que não são dependentes de nenhuma linguagem de programação específica. A implementação em código fonte deve ocorrer quando a interface dos packages se estabilizar. Nessa etapa, utiliza-se os design objects como guias, já que a maioria deles corresponde exatamente a uma classe, facilitando o mapeamento. Em outros casos algumas classes são implementadas para um dado design object, o que inclui implementação de atributos, utilização de componentes, separação de funcionalidades, etc. Isso irá garantir que que cada design object irá suportar as demais classes que forem adicionadas ao sistema. Durante esse procedimento, deve-se evitar que duas classes ofereçam funcionalidades iguais ou semelhantes, a não ser que esteja sendo utilizado um sistema de herança. Há outros meios para se criar um bom desenho de classes, mas o tempo é extenso e nem sempre se consegue obter um sistema eficiente e com classes mais genéricas. O esquema geral do processo de construção é mostrado na figura 2. A fase de

4 desenho, chamada de projeto, realiza o refinamento dos casos de uso obtidos na fase de análise e gera os diagramas e especificações necessárias para a fase de implementação. Figura 2. Etapa de Construção. Retirado de [6]. Já na fase de testes deve ser feita a verificação do sistema construído e isso deve ser feito inteiramente dentro do processo de desenvolvimento, seu esquema geral é mostrado na figura 3. Se até esse momento os envolvidos na construção tiverem feito uso da disciplina e da boa organização, essa fase terá seu custo diminuído. O grande objetivo dessa fase é, principalmente, a integração das diferentes classes criadas através da utilização de Use Cases e isso pode ser feito bem cedo, já na parte de identificação e especificação dos mesmos. Ao definir os processos e seus respectivos modelos gerados, podemos então fazer uma apanhado geral do método de Jacobson. A figura 4 ilustra como os processos são obtidos a partir dos casos de uso: primeiramente expressamos o modelo de requisitos, então estruturamos o modelo de análise especificando os casos de uso, seguido da análise de robustez do sistema. Realizamos então o modelo de desenho (design) em que especificamos a estrutura geral do sistema, tanto em relação ao domínio do mundo real quanto a nível de implementação, a partir desta especificação podemos então implementar o sistema, o que é feito no modelo de implementação. Por fim o modelo de testes permite verificar e validar a consistência do sistema.

5 Figura 3. Etapa de Teste. Retirado de [6]. Figura 4. Visão geral do Processo de desenvolvimento, tendo como base diagramas Use Case. Retirado de [8]. 3. Principais diagramas e suas aplicações na modelagem Os principais diagramas, encontrados na literatura, para definir a estrutura do sistema

6 são os diagramas de caso de uso, os diagramas de análise, diagramas de interação e de transição de estados, porém de acordo com Jacobson et al (1992) também é necessário descrever as interfaces que não podem ser contempladas pelos diagramas, que podem corresponder a interfaces externas do sistema, bem como as sequências descritas de forma textual para facilitar a implementação em uma linguagem de programação [1]. O diagrama de caso de uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. Estes diagramas são compostos por atores, que representam um usuário do sistema, podendo ser humano ou outro sistema computacional, por casos de uso que representam uma funcionalidade do sistema, e pelo relacionamento entre atores e casos de uso. Eles são produzidos na fase inicial, no modelo de requisitos de modo a facilitar a comunicação entre o analista e o cliente e para permitir que o cliente tenha uma visão geral das principais funcionalidades do sistema. Os diagramas de análise (desenvolvidos durante o processo de análise), também chamados de diagramas de classes de análise, concentram-se em identificar os conceitos do domínio do problema e transformá-los em classes de análise. Tais classes descrevem abstrações no domínio do problema do mundo real, a figura 5 ilustra um diagrama de classes, utilizado na seção 5 no estudo de caso apresentado. Os diagramas de interação são usados no modelo de desenho, incluso no processo de construção. Cada use case identificado no processo de análise recebe um diagrama de interação, que consiste em descrever a forma como é realizada a comunicação entre os objetos do caso de uso, bem como definir as mensagem (estímulos) trocadas entre eles para facilitar a fase de implementação. Dois tipos específicos de diagrama de interação são os diagramas de sequência e colaboração. Os diagramas de sequência ilustram como as mensagens são trocadas entre objetos no decorrer do tempo para realizar uma operação, a figura 6 mostra um exemplo de diagrama de sequência em que os objetos transmitem mensagens entre si. Os diagramas de colaboração são semelhantes aos de sequência, porém o tempo não é mais representado por linhas verticais e sim através de uma numeração, como mostrado na figura 7. Os diagramas de transição de estados descrevem quais estímulos podem ser recebidos e qual o resultado nos objetos ou sistema quando eles são recebidos. Estes diagramas são utilizados antes da fase de implementação e logo após a descrição dos diagramas de interação. Um exemplo simples é denotado na figura 8, que representa um diagrama de transição de estados de um semáforo, inicialmente ele se encontra em um estado e, então, recebe um estimulo para mudar de cor e passar para um novo estado que representa uma nova situação.

7 Figura 5. Diagrama de classes de análise. Retirado de [5]. Figura 6. Exemplo de um diagrama de sequência. Retirado de [3].

8 Figura 7. Exemplo de um diagrama de colaboração. Retirado de [3]. Figura 8. Diagrama de transição de estados de um semáforo. Retirado de [4]. 4. Principais heurísticas

9 Temos como características do método OOSE, UML como linguagem de modelagem, Direcionado por casos de uso, Centrado na arquitetura, Iterativo, Incremental. O que reflete nas seguintes etapas: Concepção: estudo de viabilidade, análise de riscos e elicitação dos principais requisitos; Elaboração: determina a arquitetura e os componentes para o projeto, junto com protótipos iniciais; Construção: completa o desenvolvimento com base na arquitetura inicial. Em suma, são características que acompanham do início ao fim de um projeto, não podendo ser esquecidas, se bem aproveitadas o resultado tende a satisfazer o propósito do projeto. 5. Estudo de caso Sistema para Controle de Bibliotecas [5], será construído um software para controlar o empéstimo e a devolução de exemplares de uma biblioteca. O usuário pode fazer um empréstimo de um exemplar durante um certo período e, ao final desse tempo, o exemplar deve ser devolvido. Renovações não são aceitas. A atendente é uma funcionária que interage com os usuários e com o sistema de controle da biblioteca através de um terminal. Dadas as características, serão seguidos os seguintes passos: 1) Criação dos diagramas de casos de usos; 2) Identificar Classes de Análise; 3) Estabelecer o domínio; 4) Construir um dicionário de dados; 5) Criar relacionamento entre as classes de Análise; 6) Identificar/Refinar atributos; 7) Iterar e refinar. Como produto final temos um ótimo diagrama de classes de Análise baseado em um método de análise Orientado a Objetos. 6. Referências [1] YAMAGUTI, Silvio Yochio. Orientação a Objetos no Desenvolvimento de Sistemas: Conceitos e Características. Engenharia de Sistemas PósGraduação Lato Sensu da Escola Superior Aberta do Brasil - ESAB. monografia_9850_v1.pdf [2] GNHOATO, André Ricardo; JUNIOR, Antônio Carlos Gimenez; KAZUOMATSUMOTO, Henrique. Linguagem de Modelagem Orientada a Objetos. Histórico e Aplicabilidade da UML(Unified Modeling Language). Instituto de Informática, Universidade Tecnológica Federal

10 do Paraná. Historico-e-Aplicabilidade-da-UML-Unified-Modeling-Language [3] SAMPAIO, Marcus Costa; NETO, Eloi Rocha. Material sobre UML. Universidade Federal de Campina Grande. interacao/interacao.htm [4] Diagrama de Transição de Estados. Diagrama_de_transi%C3%A7%C3%A3o_de_estados [5] CARVALHO, Ariadne. Modelagem Estática. Engenharia de Software, UNICAMP. [6] BORGES, Gilene do Espírito Santo; NASCIMENTO, Maria Elenita Menezes. Uma avaliação de Métodos Orientados a Objetos e Modelos de Processo. Universidade de Brasilia. pt.scribd.com/doc/ /52/metodo-oose [7] BRETERNITZ, Vivaldo José. Uma introdução ao software baseado em objetos. br.monografias.com/trabalhos/uma/uma.shtml [8] Carlos; Jardel; Ricardo; Sandro. Modelo OOSE. Faculdade de Informática de Taquara. [9] ASTIAZARA, Mauricio Volkweis; SOUZA, Marcelo Waihrich. Objectory. Universidade Luterana do Brasil.