Engenharia de Software Orientada a Objetos

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
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
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
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.
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
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.
Figura 5. Diagrama de classes de análise. Retirado de [5].
Figura 6. Exemplo de um diagrama de sequência. Retirado de [3].
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
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. www.esab.edu.br/arquivos/monografias/
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
do Paraná.
http://pt.scribd.com/andregnhoato/d/33369212-Linguagem-de-Modelagem-Orientada-a-ObjetosHistorico-e-Aplicabilidade-da-UML-Unified-Modeling-Language
[3] SAMPAIO, Marcus Costa; NETO, Eloi Rocha. Material sobre UML. Universidade Federal
de Campina Grande. http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/
interacao/interacao.htm
[4] Diagrama de Transição de Estados. http://pt.wikipedia.org/wiki/
Diagrama_de_transi%C3%A7%C3%A3o_de_estados
[5] CARVALHO, Ariadne. Modelagem Estática. Engenharia de Software, UNICAMP. http://
www.ic.unicamp.br/~ariadne/mc436/1s2012/cap03.pdf
[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. http://
pt.scribd.com/doc/82863321/52/Metodo-OOSE
[7] BRETERNITZ, Vivaldo José. Uma introdução ao software baseado em objetos. http://
br.monografias.com/trabalhos/uma/uma.shtml
[8] Carlos; Jardel; Ricardo; Sandro. Modelo OOSE. Faculdade de Informática de Taquara.
http://fit.faccat.br/~franzen/analise2/oose/
[9] ASTIAZARA, Mauricio Volkweis; SOUZA, Marcelo Waihrich. Objectory. Universidade
Luterana do Brasil. http://pt.scribd.com/doc/31791340/Objectory