Você está na página 1de 15

1.

Introduo Anlise e Projeto de Sistemas Orientados a Objetos


O princpio dos estudos da anlise de sistemas deve partir, inevitavelmente, da
compreenso do que um sistema. Em seguida pode-se enquadrar este entendimento
na realidade dos sistemas computacionais, que o foco do presente trabalho.
Em nvel geral, pode-se caracterizar um sistema como sendo um conjunto de
elementos interdependentes, ou um todo organizado, ou partes que interagem
formando um todo unitrio e complexo. Dividindo-se, ainda, os sistemas em fechados e
abertos, os primeiros no estabelecem troca de material com o ambiente externo, ou
seja, nenhum "material" entra ou deixa o sistema. Exemplos de sistemas fechados so
os sistemas de simulao, os quais, em geral, so projetados com o intuito de viabilizar
qualidade e otimizar posteriores projetos de sistemas abertos.
Contrariamente queles, os sistemas abertos se caracterizam por realizar
constante troca de materiais com o meio em que esto inseridos. Os exemplos para
estes so dos mais variados, podendo-se citar os sistemas de transporte, o corpo
humano, os sistemas econmicos e sociais e, dentre os mais comuns para nossos
estudos, as empresas/corporaes. Portanto, na grande maioria das vezes, nas tarefas
de anlise e projeto, os esforos iro se concentrar nos sistemas abertos.
Um sistema aberto composto de um conjunto de partes em constante interao
(interdependncia das partes), constituindo um todo orientado para determinados fins e
em permanente relao de interdependncia com o ambiente externo. E as empresas,
por que se comportam como sistemas abertos? O ambiente em que elas se encontram
essencialmente dinmico, forando o sistema organizacional (para sobreviver) a
responder com eficcia s presses exercidas pelas rpidas e contnuas mudanas no
ambiente. Os sistemas ainda podem ser divididos em vrios subsistemas, os quais
tambm se caracterizam em um conjunto de partes interdependentes que se
relacionam entre si, compondo um sistema maior.
Usando das definies acima, podemos decompor alguns sistemas:
- Corpo humano: sistema sseo, circulatrio, muscular, etc.
- Sistema de transportes: rodovirio, metrovirio, ferrovirio, de carga, areo,
martimo, etc.
Os sistemas abertos so baseados na idia de que determinadas entradas (inputs)
so introduzidas no sistema e, uma vez processados, geram certas sadas (outputs). As
empresas assim se comportam atravs de recursos materiais, humanos e tecnolgicos,
cujo processamento resulta em bens ou servios a serem fornecidos ao mercado.
Desta forma podemos definir, agora, um sistema de informao em funo de
subsistemas e de empresas. Um sistema de informao formado por outros

subsistemas, cada qual sendo um sistema de informao apoiando um processo de


deciso. Assim sendo, um sistema de informao pode ser definido como um conjunto
de componentes inter-relacionados trabalhando juntos para coletar, recuperar,
processar, armazenar e distribuir informao com a finalidade de facilitar o
planejamento, o controle, a coordenao, a anlise e o processo decisrio em empresas
e outras organizaes (Laudon, 1999). Portanto, cada sistema/subsistema pode ser
decomposto em 3 partes principais, conforme figura 1.1, sendo:
1 - Coleta de dados de entrada;
2 - Processamento dos dados;
3 - Produo e distribuio de dados de sada (informaes).

Figura 1.1 Atividades dos Sistemas de Informao: Entrada,


Processamento e Sada
De forma geral, til destacar os principais aspectos que descrevem o conceito
dos sistemas de informaes:
- O sistema total uma extenso do processamento integrado de dados que
resulta na integrao de todos os subsistemas principais num nico sistema;
- O sistema deve incorporar as informaes necessrias para planejamento e
controle;
- O sistema deve gerar informaes necessrias para auxiliar os
administradores de todos os nveis a atingirem seus objetivos;
- O processamento eletrnico de dados deve representar um papel
importante, porque se torna necessrio automatizar para prover informaes exatas
rapidamente.
possvel verificar que a viso sistmica no necessariamente passaria pelos
ambientes computacionais, pois j existiam antes destes. No entanto, h muito j se
tornou difcil conceber um sistema de informaes sem o suporte de ferramentas e
4

sistemas de software e hardware. Portanto, no demais relacionar os conceitos vistos


at ento, com o campo de processamento de dados, e afirmar que os sistemas sero
tratados como um conjunto de pessoas, mquinas e mtodos organizados de modo a
cumprir um certo nmero de funes especficas.
Todavia, exatamente a viso sistmica, independente da tecnologia em questo,
que deve ser adotada quando se comear a estudar e proceder com as tarefas iniciais
da anlise de sistemas. Ento, o que fazer anlise? Confunde-se, muitas vezes, que
analisar somente resolver problemas. Porm, anlise o estudo de um problema, que
antecede tomada de uma deciso/ao. J em relao ao nosso foco de trabalho - os
sistemas computacionais -, anlise o estudo de alguma rea de trabalho ou de uma
aplicao, levando geralmente especificao de um novo sistema. Esta ao ser o
projeto e a implementao do mesmo.
No princpio da informtica, geralmente os problemas a serem resolvidos eram de
carter especificamente matemticos. Eram adotados mtodos cientficos de resoluo
de problemas e passava-se implementao das solues. Os programadores
comearam a adotar ferramentas de modelagem, sendo os fluxogramas as mais
utilizadas. Estes se mostraram voltados unicamente especificao da soluo
algortmica sem, contudo, permitir aos analistas da poca que se concentrassem no
domnio do problema em que se estava envolvido.
Neste momento da histria do desenvolvimento de software surgiu a necessidade
de se ter ferramentas e, principalmente, mtodos sistemticos que auxiliassem o
profissional de software a percorrer o caminho da anlise e projeto de sistemas. Foram
ento elaboradas abordagens mais completas. Eram as primeiras metodologias de
anlise e projeto de sistemas, as quais usavam de tcnicas e ferramentas de
modelagem, sendo as mais expressivas os diagramas de fluxo de dados (DFD) e os
modelos entidade-relacionamento (E-R). Surgia, assim, a anlise e projeto de sistemas
estruturados.
Nesta poca j havia as primeiras propostas de processos de construo de
software. Portanto, desde ento, a adoo de mtodos sistemticos de anlise e projeto
se mostrou extremamente necessria. Alm do processo de programao, um mtodo
sistemtico deve abranger tambm as demais fases do processo de construo de
software. Em geral, a grande maioria das metodologias deve pressupor as fases de
definio de requisitos, anlise, projeto, implementao e testes. Esta abordagem pode,
contudo, variar, dependendo dos objetivos de quem props o mtodo e, claro, de quem
o utiliza. Alm disso, vrias atividades especficas engenharia de software tambm
devero ser consideradas quando se planeja construir um produto de software com
qualidade, o que ser tratado na seo a seguir.
Como principais caractersticas em se ter um mtodo, cita-se:
- Oferecer sistemtica para as fases de definio de requisitos, anlise, projeto,
5

implementao e testes;
- Evitar codificao precoce: programas de difcil manuteno e que no
satisfazem os requisitos do usurio;
- Mtodos sistemticos consomem mais tempo nas fases iniciais do
desenvolvimento de software, mas minimizam erros no projeto e implementao e
viabilizam software com maior qualidade.
Com o surgimento do paradigma de programao orientado a objetos, a histria
quase se repetiu, ou seja, se implementava sistemas sob um determinado prisma, mas
a especificao do mesmo estava sendo feita, ainda, de maneira estruturada. Contudo,
isto normal no processo de evoluo tecnolgica, o que logo gerou a necessidade por
mtodos de anlise e projeto orientados a objetos.
Vrias metodologias foram desenvolvidas e apresentavam inmeras vantagens,
conforme elencados por Coleman (1996):
-

Verificao de requisitos;
Conceitos mais claros;
Maior adequao do projeto ao problema;
Melhor decomposio do projeto para trabalho em equipe;
Melhor comunicao da equipe de desenvolvimento;
Menor esforo de manuteno;

Todo o assunto at aqui abordado tem como nico objetivo situar o leitor para o
que vir a frente. Contudo, o tema discutido sugere leituras complementares em
relao a sistemas de informao e a outras metodologias de anlise e projeto, j que
este aprofundamento sairia do escopo deste projeto, restringindo-nos em apresentar
uma metodologia em particular de anlise e projeto de sistemas orientados a objetos.
No restante deste captulo so desenvolvidos conceitos introdutrios para o
trabalho orientado a objetos, na seo 1.1, sem aprofundarmo-nos no assunto, o que
ser feito no momento adequado do processo. Em seguida, na seo 1.2, feito um
apanhado geral sobre o histrico das metodologias de desenvolvimento orientadas a
objetos e sobre o mtodo Fusion, dando seqncia com um breve resumo sobre a UML
na seo 1.3, sendo estas duas abordagens os pilares para o projeto FILM. O presente
captulo finalizado com a seo 1.4, onde se apresenta a estrutura resultante
proposta pelo projeto FILM - Mtodo Fusion Expandido e Adaptado UML por
Galimberti (2002), no qual fornecida uma viso geral do processo que poder ser
adotado no transcorrer dos trabalhos de anlise e projeto de sistemas orientados a
objetos.

1.1. Anlise e Projeto Orientados a Objetos


A orientao a objetos surgiu como uma abordagem de programao que procura
explorar o nosso lado intuitivo. Os "tomos" da computao orientada a objetos (os
prprios objetos), so anlogos aos objetos existentes no mundo fsico, o que produz
um modelo de programao muito diferente da tradicional viso "funcional" e
"procedimental" (Coleman, 1996).
A viso do modelo computacional orientado a funes poderia ser assim resumida:
- Os "tomos" da computao so as funes;
- As funes atuam sobre um nico estado compartilhado;
- Qualquer funo pode atuar sobre qualquer parte do estado
compartilhado.
J no modelo computacional orientado a objetos:
- A nica maneira de se obter ou alterar o estado de um objeto pelo envio
de mensagens;
- Cada objeto responsvel pela resposta a uma determinada mensagem;
- Os objetos, quando compartilham uma nica interface, so agrupados em
classes.
Durante a execuo do sistema, os objetos podem ser construdos ou destrudos,
podem executar aes ou se tornar inacessveis: estas caractersticas o tornam um
modelo computacional dinmico. Assim sendo, os tomos do processo de computao
so os objetos:
- Os objetos trocam mensagens entre si;
- As mensagens resultam na ativao de mtodos;
- O emissor da mensagem no precisa saber como o objeto receptor
organiza o seu estado interno;
- Ao emissor da mensagem basta saber que o objeto receptor/servidor
responde a certas mensagens de maneira bem definida.
Entretanto, o paradigma orientado a objetos deve, alm do processo de
programao, abranger tambm as demais fases do processo de desenvolvimento de
sistemas computacionais. Um dos aspectos mais importantes e comuns entre os
mtodos de anlise e projeto de sistemas orientados a objetos viabilizar uma
hierarquia com as especificaes das classes de objetos que devero ser
implementadas para formar o software. Para que isto ocorra, cada metodologia deve
especificar caminhos entre a definio de requisitos e a definio da arquitetura do
software orientado a objetos, sendo que neste trajeto vrios so os artefatos de
software produzidos com o objetivo de otimizar o processo de estruturao das classes
de objetos.
7

Historicamente foram desenvolvidas metodologias para tratar o ciclo de


desenvolvimento de software sob o ponto de vista de objetos. Contudo, como um
processo natural de evoluo de "novas" tecnologias, este tema ainda proporciona
novas propostas de abordagem para o assunto, gerando, ao mesmo tempo,
divergncias e similaridades entre as mesmas, sejam mtodos ou mesmo processos
completos de engenharia de software.
Voltando a referenciar nossa breve conversa sobre a anlise de sistemas e sua
histria, vrios estudiosos concluram sobre a necessidade de abordagens que
auxiliassem o profissional da rea a construir software. Foram ento desenvolvidas
inmeras pesquisas e experincias, tanto na academia como na indstria. Como
resultados dos projetos de pesquisa surgiram diversas metodologias de anlise e
projeto de sistemas, mas tambm linguagens de especificao, ferramentas e tcnicas
de modelagem de sistemas orientados a objetos. Assim, vrios trabalhos no se
caracterizam necessariamente como mtodos de anlise e projeto, mas tambm
contribuem em muito para este campo da informtica. Assim sendo, at especificar
suas caractersticas, trataremos estes trabalhos, genericamente, como abordagens de
anlise e projeto orientados a objetos.
Dentre as principais abordagens (mtodos, tcnicas, linguagens de especificao)
conhecidas mundialmente, e altamente influentes para este trabalho, citam-se:
"Booch", de Grady Booch; "OMT (Object Modeling Technique)", de James Rumbaugh;
"Objectory", de Ivar Jacobson; "CRC (Class- Responsability-Collaboration)", de Kent
Beck; "RUP (Rational Unified Process)", dos "Tree Amigos", assim comumente
conhecidos os pesquisadores Booch, Rumbaugh e Jacobson, que juntos eram
proprietrios da Rational Software Corp. Alm destas, tem-se como atualmente
influentes para avanos do FILM as abordagens ditas geis, sendo XP - Extreme
Programming e AM - Agile Modeling, respectivamente de Kent Beck e Scott Ambler.
Devido a esta miscelnea de mtodos, surgiram duas boas abordagens com
propostas de fuso de conceitos, sendo elas: Fusion (Coleman, 1996) e UML (Unified
Modeling Language) (OMG, 2001). Estas se caracterizam como a base de nossas
atividades e so apresentadas a seguir.
Atualmente sendo adotada como base para a prtica da orientao a objetos nas
disciplinas de Anlise e Projeto de Sistemas, seguindo os currculos dos cursos de
Bacharelado em Cincia da Computao e Tecnologia em Processamento de Dados da
Universidade de Caxias do Sul, o mtodo Fusion se apresenta bastante sistemtico e
didtico para o processo de desenvolvimento de software orientado a objetos,
estabelecendo uma rota direta entre a definio dos requisitos e a implementao do
sistema. No entanto, os modelos por ele criados sugerem adequaes devido a
similaridade de notao entre os mesmos e, principalmente, por no ter a padronizao
necessria ao segmento de objetos. Alm disso, o mtodo no prope abordagem para
a definio de requisitos, que uma das fases iniciais do processo de produo de
8

software, que precede as atividades de construo do mesmo.


J em relao UML, esta caracteriza-se como um conjunto de notaes bem
definidas e especficas para a construo dos diversos artefatos necessrios desde a
definio de um sistema orientado a objetos at a sua implementao. A UML
necessita, contudo, de um mtodo que indique quais os passos a serem dados para se
construir o sistema de software, conforme ser melhor abordado na seo seguinte.

1.2. Mtodo Fusion de Anlise e Projeto Orientado a Objetos


O mtodo Fusion de anlise e projeto de sistemas orientados a objetos foi
concebido dentro dos laboratrios da empresa Hewlett-Packard tendo como motivao
sistematizar o processo de construo dos sistemas de software em demanda na
corporao.
O mtodo Fusion caracteriza o centro dos estudos para nossa abordagem de
orientao a objetos. Neste contexto, apresenta-se na traduo de uma fuso de
conceitos, sintetizando os melhores recursos de abordagens populares de modelagem
de sistemas orientados a objetos.
O mtodo Fusion no "engloba" a captura de requisitos, no possuindo uma fase
destinada a isto. Portanto, o mtodo prev que os requisitos sejam fornecidos por
usurios e documentados seguindo-se alguma tcnica de elicitao e de especificao
de requisitos "qualquer", passando-se em seguida fase de anlise.
J na na fase de anlise, o propsito definir "o que" o sistema faz e no "como"
feito. Em contraste com outros mtodos, na anlise do Fusion no so associados
mtodos s classes, o que deve ser feito na fase de projeto. Em geral, a fase de anlise
comporta os seguintes aspectos:
- Identificar os objetos e as classes existentes no sistema e seus
relacionamentos;
- Definir o comportamento esperado do sistema em termos de eventos de
entrada e sada;
- Os modelos do sistema so produzidos descrevendo os seguintes
elementos:
- Classes de objetos que existem no sistema;
- Relacionamentos entre essas classes;
- Operaes que podem ser executadas no sistema;
- Sequncias permissveis para eventos de entrada e de sada;
Na fase de projeto o objetivo definir como sero implementadas as operaes
do sistema atravs do comportamento dos objetos em tempo de execuo. Durante a
9

fase de projeto, as operaes so associadas s classes e os modelos gerados


documentam o que segue:
-

Operaes so divididas em interaes de objetos;


Objetos fazem referncias mtuas entre si;
As operaes so implementadas pelas interaes entre os objetos;
As classes se relacionam por herana;
Os atributos constam nas classes juntamente com os mtodos;

O mtodo Fusion tem ao seu final uma fase de implementao. O autor prope o
uso de mquinas de estados, complementando a fase de projeto, mas tem como meta
transformar o projeto em cdigo-fonte orientado a objetos. Segue abaixo as
orientaes do Fusion para esta transformao do projeto em cdigo:
- Herana, referncias e atributos das classes so codificados nas classes
especficas;
- Interaes entre objetos so transformadas nos mtodos pertencentes a
uma classe selecionada;
- Mquinas de estado so usadas para se reconhecer as sequncias
permitidas para as operaes;
- Tambm so consideradas tcnicas de inspeo e teste para avaliao de
sistemas orientados a objetos.
Dicionrio de Dados: caracteriza-se como um artefato de software que adotado
e alimentado durante todo o processo de construo do software e identifica as
entidades existentes no sistema. Este artefato serve de referncia durante todo o
processo de construo do software.

1.3. Padres de Modelagem de Objetos usando UML - Unified


Modeling Language
A UML teve seu desenvolvimento iniciado em outubro de 1994 quando Grady
Booch e Jim Rumbaugh, da Rational Software Corporation, comearam seus trabalhos
de unificar os mtodos Booch e OMT. Em 1995 juntou-se com aqueles Ivar Jacobson,
unindo sua companhia Rational e sua proposta de Engenharia de Software Orientada
a Objetos (OOSE), atravs do processo Objectory 3.8, passou a colaborar com a
proposta da UML.
Booch, Rumbaugh e Jacobson, trs autores de renome internacional, conhecidos e
referenciados mundialmente como "The Three Amigos" (isso, assim mesmo), extraram
de suas metodologias anteriores aspectos positivos de cada uma delas de maneira a
formular a UML. As experincias destes profissionais mostraram ser ineficiente uma
metodologia estanque e que no se adequasse a outros processos de desenvolvimento
10

de software. O que os motivou criao da UML como uma linguagem flexvel, que
pudesse se adaptar a outras metodologias j existentes ou que por ventura viessem a
ser criadas.
A partir deste quadro mundial, havia sido criada uma comisso internacional,
denominada Object Management Group (OMG) (OMG, 2004), que iniciou um processo
de padronizao da rea de orientao a objetos. Assim, a OMG reconheceu a UML 1.3
com exclusividade, em 1996, como padro de linguagem notacional para construo de
artefatos de sistemas orientados a objetos. Atualmente a UML encontra-se na verso
1.5, estando em processo constante de avaliao e ajustes junto OMG para evolues
em sua proposta. Em 2001, membros da OMG iniciaram o trabalho de uma evoluo
para a UML 2.0, o qual mantido organizado por quatro RFPs (Requests for Proposal)
sendo: UML Infrastructure, UML Superstructure, Object Constraint Language, e UML
Diagram Interchange.
Partindo para a sua definio, a UML uma linguagem grfica para visualizar,
especificar, construir e documentar os artefatos de um sistema de software. A UML
oferece uma forma padro para se escrever/modelar projetos de sistemas, incluindo
conceitos, tais como processos de negcios e funes de sistema, bem como 'coisas'
concretas como sentenas de linguagem de programao, projetos de bancos de dados
e componentes reutilizveis de software (Booch, 1998).
Em termos de estrutura, para este trabalho suficiente, por enquanto, sabermos
que a UML define doze tipos de diagramas, divididos em trs categorias: quatro tipos
de diagramas representam a estrutura esttica de uma aplicao; cinco outros
diagramas representam diferentes aspectos do comportamento dinmico da aplicao;
e outros trs representam maneiras como voc pode organizar e gerenciar os mdulos
da aplicao (OMG, 2004).

Diagramas Estruturais:

Diagramas de Classes;

Diagramas de Objetos;

Diagramas de Componentes;

Diagramas de Implantao / Disposio Fsica (Deployment Diagram);

Diagramas Comportamentais:

Diagramas Use Case;

Diagramas de Sequncia;

Diagramas de Atividade;
11

Diagramas de Colaborao;

Diagramas de Estado;

Diagramas Gerenciais:

Pacotes;

Subsistemas;

Modelos;

Alm dos diagramas, a UML viabiliza outros mecanismos gerais tais como notas,
contratos, etc. Contudo no iremos abordar cada pormenor da UML, pois contm um
conjunto de notaes relativamente extenso. No restante dos captulos sero
apresentados os aspectos diagramticos necessrios aos nossos trabalhos, j que no
necessria a utilizao de todas as notaes e diagramas da UML para a customizao
de um processo ou mtodo de desenvolvimento de software.
A UML, portanto, no se caracteriza como um mtodo ou processo de construo
de software e sim uma linguagem comum para expressar os diversos modelos, ou seja,
no informa "como se faz" para desenvolver software. Conseqentemente, diversos
mtodos e processos de desenvolvimento efetivo de software continuaro a ser criados,
porm podero ser feitos usando a UML como uma linguagem comum. De pronto
podem ser citados o RUP, de Jacobson (1998) e a proposta, bastante didtica, de
Larman (2000). Esta realidade tambm vem a motivar que empresas de
desenvolvimento, que adotam mtodos e processos proprietrios/particulares para
construo de software, possam se adequar a um padro mundial de orientao a
objetos de maneira customizada aos seus ambientes de desenvolvimento.
A flexibilidade da UML e sua padronizao justificam sua utilizao em nosso
trabalho. A partir da prxima seo comearemos a abordar o processo que
utilizaremos para construir software e quais sero os diagramas e notaes UML que
faremos uso para tornar a modelagem dos artefatos do software inteligveis.

1.4. Mtodo Fusion Expandido e Adaptado UML


A partir desta seo abordado o tema principal deste trabalho, o qual tem como
alicerce os resultados obtidos com o projeto FILM forma simblica de referenciar o
projeto denominado Mtodo Fusion Expandido e Adaptado UML, tendo sido
institucionalizado na Universidade de Caxias do Sul, dentro do Departamento de
Informtica, com apoio da Pr-Reitoria de Pesquisa e Ps-Graduao e pela FAPERGS Fundo de Amparo Pesquisa do Estado do Rio Grande do Sul (Galimberti, 1999). O
Projeto FILM, oficialmente iniciado no ano 2000, tinha a proposta original de adaptar o
mtodo Fusion de anlise e projeto de sistemas orientados a objetos com uma
12

linguagem padro de modelagem, sendo que a proposta do projeto e as primeiras


atividades desenvolvidas tiveram resultados preliminares ainda em 1999, com o
trabalho acadmico de Migot (1999). A importncia da reformulao do mtodo se
concentrava na eficincia e clareza dos modelos gerados por aquele mtodo, sendo que
os mesmos podiam ser considerados, s vezes, como incompletos e com notaes
pouco especificadas para o trabalho didtico em cursos de graduao. A proposta
tambm expandia o espectro do mtodo Fusion, acrescentando ao mesmo a
abordagem da fase inicial de especificao de requisitos, a qual no era considerada na
verso original do mtodo, e desenvolvida em sua primeira verso pelo acadmico
Franzen (1999).
Para a expanso do mtodo e adequao de seus modelos, utilizou-se da Unified
Modeling Language (UML). Conforme j visto, a UML considerada padro mundial
para modelagem de sistemas pelo Object Management Group (OMG), e prope
flexibilidade aos diversos processos de desenvolvimento de software, possibilitando
expanso dos mtodos orientados a objetos e disponibilizando um conjunto de
notaes para a construo dos modelos da orientao a objetos.
Este contexto, aliado ao fato de existir proposta semelhante, quando da
adequao da UML ao processo Objectory de Engenharia de Software, atravs do
trabalho "UML Extension for Objectory Process for Software Engineering", veio a
motivar o presente trabalho, com o qual buscou-se utilizar a UML para acrescentar
clareza, eficincia e padronizao construo dos artefatos propostos pelo mtodo
Fusion. Alm disso, viabilizou-se a expanso do mtodo Fusion em relao fase inicial
de definio de requisitos, enquadrando-se notaes da UML para a gerao de
artefatos para esta fase.
No entanto, a principal motivao para a criao deste trabalho vem da atual
estrutura curricular dos cursos do Departamento de Informtica desta universidade e,
consequentemente, da insero de seus egressos no mercado de desenvolvimento de
software. Sendo estes cursos formadores de profissionais empreendedores com perfis
de analistas e projetistas de software, considera-se que os mesmos devem estar
sintonizados com o contexto mundial da tecnologia e dos padres de orientao a
objetos. Deve-se, portanto, considerar o processo gradativo de mudana do paradigma
estruturado pelo orientado a objetos, pelo qual passam as empresas do setor de
informtica da regio, o que as est levando a adotar padres estabelecidos para o
segmento de produo de software.
Assim sendo, para que a adaptao do mtodo fosse calibrada e concluda, foram
desenvolvidos muitos estudos de caso, em vrias frentes acadmicas e outros projetos.
Vale citar os mais de 40 trabalhos de estgio, no curso de Tecnologia em
Processamento de Dados, que utilizaram dos resultados deste projeto para guiarem o
desenvolvimento de seus software.
13

O Projeto FILM tambm foi validado com a construo de uma ferramenta de


software de clculo de motores eltricos, em parceria com a empresa Eberle e
financiamento da FAPERGS, atravs do projeto Ferramenta de Clculo de Motores
Eltricos de Induo Trifsicos e Monofsicos (ProMot). Este projeto permitiu o
amadurecimento do mtodo FILM, originando estudos para acadmicos de graduao
em Cincia da Computao sobre tcnicas de inspeo de artefatos de software
(Zanotto, 2001) e no campo de mapeamento de modelos de objetos para camada de
armazenamento de dados (Mattiuz, 2002). Contudo, a contribuio maior ainda estava
por vir, que foi a evoluo de um mtodo para um processo mais completo de produo
de software. Definiu-se, ento, um processo misto de desenvolvimento de software,
sendo composto, em um primeiro estgio, por um Processo Linear e, em seguida, por
um Processo Cclico (mais especificamente, um Processo Incremental-Iterativo).
Outra agradvel surpresa com o projeto FILM foi o incio do desenvolvimento de
um interessante estudo de caso que se caracterizou em uma experincia de excelentes
resultados, sendo que no estava previsto quando da proposta deste projeto e foi
idealizado com o desenrolar das pesquisas. Trata-se de mdulos de uma ferramenta de
software de auxlio engenharia de software, comumente conhecida como CASE
(Computer Aided Software Engineering), e que tambm gerou os trabalhos dos
acadmicos Lazzari (2001) e Vieira (2002). Esta ferramenta, chamada CASE FILM, foi
construda conforme as orientaes do mtodo FILM e se prope a auxiliar os
profissionais e estudantes da rea de engenharia de software a conduzirem seus
projetos de software conforme o mtodo defendido por esta pesquisa.
Ressalta-se, ainda, o objetivo de viabilizar ao profissional habilidades suficientes
para que possa optar por outros processos de construo de software. Isto poderia ser
feito a qualquer momento, usando-se, por exemplo, o processo RUP ( Rational Unified
Process), o qual est bastante difundido mundialmente. No entanto, sob o ponto de
vista didtico, justifica-se a adoo de mais de uma abordagem de APOO, no nosso
caso o Fusion, a UML, a Definio de Requisitos por Objetivos e, mais recentemente,
adaptao de prticas de modelagem gil, pois assim o acadmico e profissional de
engenharia de software poder visualizar as vantagens em se conhecer como adaptar
um determinado mtodo realidade de construo de software nas empresas em que
iro atuar.
Numa relao de troca permanente, este projeto est auxiliando o ensino da
disciplina de engenharia de software e, em especfico, guiando as disciplinas de anlise
e projeto de sistemas atravs do Guia FILM de Anlise e Projeto de Sistemas Orientados
a Objetos. Por outro lado, a aplicao do "novo" mtodo como contedo curricular est
ajudando na validao e adequao progressiva do mesmo. Este objetivo se completa
ao situar o egresso dos cursos supra citados no cenrio atual de desenvolvimento de
software, viabilizando ao mesmo a construo de conhecimento atualizado e
sintonizado com os padres internacionais j estabelecidos, como o caso da UML que
est sendo adotada h muito pela indstria de informtica mundial e mais
14

recentemente na regio de Caxias do Sul.


Para a fase de Definio e Especificao de Requisitos o projeto colaborou na
construo da proposta Um Modelo de Estruturao de Requisitos para o Mtodo
Fusion (Rocco, 2001), sendo seus resultados utilizados pelo FILM na fase inicial do
processo. No entanto, dependendo dos objetivos e carga horria de um curso de APOO,
possvel partir de especificaes textuais e, na Anlise e Projeto Orientados a Objetos,
preferencialmente, adotar use cases para a definio de requisitos.
A estrutura geral dos resultados alcanados com o projeto FILM ser apresentada
com o que h em termos de processos e fases de construo de sistemas de software
orientados a objetos, conforme podemos analisar na figura 1.2. Em seguida, dentro de
cada captulo, cada fase ser tratada de forma separada e expandida, permitindo uma
visualizao detalhada do que deve ser modelado em cada uma de suas atividades
internas, o que ser expresso a partir de diagramas de atividades.

Figura 1.2 Modelo do Processo FILM para Construo de Software


O modelo acima permite visualizar a estrutura geral do FILM atravs dos seus
processos e de suas fases. O FILM prev um processo misto para tratamento das fases
do mtodo, sendo inicialmente conduzido por um Processo Linear e, em seguida, por
vrias iteraes em um Processo Cclico (Incremental-Iterativo).
O Processo Linear, ao ter como meta a estruturao dos objetivos de negcio e os
requisitos do sistema, preparando o incio da construo iterativa e incremental, est
15

composto por duas fases, sendo: fase de Definio e Especificao de Requisitos e a


fase de Planejamento dos Ciclos de Construo do Software.
J o Processo Cclico caracteriza-se pela diviso do projeto em construo em
unidades menores, mas com propriedades de verses operacionais, as quais podem ser
liberadas aos clientes/usurios. Uma iterao como um miniprojeto que resulta em
uma verso operacional incremental (e, espera-se, melhorada) do sistema em relao a
iterao anterior. Cada iterao, em geral, deve percorrer todas as fases do Processo
Cclico, sendo as fases de Anlise, Projeto, Implementao e Testes. Vale enfatizar que
o FILM tem como foco as fase de Anlise e Projeto, buscando estruturar e orientar o
prosseguimento para as fases de Implementao e Testes.
Este processos e fases sero devidamente conceituados ao longo do trabalho. Nos
dois prximos captulos sero tratadas as duas primeiras fases do Processo Linear. A
partir do captulo 4 inicia-se o Processo Cclico, sendo dedicado, tambm, um captulo
para cada uma de suas fases.
A organizao dos demais captulos compreende o detalhamento das fases e suas
atividades no sentido de facilitar ao leitor sua compreenso e aplicao. Sero
apresentados os refinamentos das fases do processo de desenvovimento de software,
sendo fornecidos fluxos de atividades, descrio de artefatos de entrada e sada e
orientaes estratgicas para a construo dos artefatos de software. O Processo FILM
de Construo de Software ser apresentado, portanto, na seqncia de seus processos
Linear e Cclico, onde para cada uma das fases e atividades sero tratados os seguintes
tpicos:

Fundamentao conceitual da fase do processo: feita uma introduo que


oferece uma viso do que est includo na fase, seus principais objetivos e
correlao com o fluxo de atividades da fase (workflow).

Workflow da fase: visualizao da seqncia de realizao das atividades da


fase.

Cada atividade apresentada no fluxo de atividades ser detalhada conforme os


itens a seguir:

Fundamentao conceitual da atividade e descrio dos objetivos da


mesma;

Descrio dos trabalhadores envolvidos na atividade;

Descrio dos artefatos de entrada necessrios atividade;

Descrio dos artefatos produzidos durante a atividade, ou seja, os


artefato de sada da atividade;
16

Estratgias e Notaes para Modelagem: este tpico tem o propsito de


orientar o leitor para a realizao da atividade e modelagem de artefatos,
alm de especificar a estrutura notacional a ser utilizada na atividade;

Estudo de caso: buscando facilitar o aprendizado, foram trabalhados em


sala de aula diversos estudos de casos desenvolvidos no Processo FILM.
Contudo, verificou-se que poderiam haver benefcios didticos em se ter
um trabalho mais simples e compacto para sala de aula. Ento foi iniciada
a especificao de um sistema para controle de uma biblioteca virtual
departamental, comumente sendo chamada MiniBib neste trabalho. Em
seguida este tema foi oferecido como sugesto para trabalho de estgio
para auxiliar o projeto FILM. Esta proposta foi continuada e disponibilizada
por este projeto atravs do acadmico DeBona (2002) com o intuito de
oferecer um material menos complexo e mais aplicvel pelos estudantes
de anlise e projeto de sistemas. Ao longo das atividades deste guia sero
selecionados pequenos trechos do estudo de caso, adaptando-se o
mesmo, em sua totalidade (exceto a prpria implementao por no ser o
escopo deste guia), no apndice deste trabalho.

Inspeo dos artefatos da fase: este tpico apresentado ao final de cada


captulo e tem como objetivo prover qualidade final ao produto de software
atravs do tratamento da qualidade parcial de cada um dos artefatos
desenvolvidos ao longo das fases. So prestadas orientaes aos trabalhadores
da fase no sentido de dar subsdios tcnicos para a verificao e inspeo dos
artefatos desenvolvidos em cada atividade. Optou-se por abordar este tema ao
final dos captulos, mas as orientaes trataro de todas as atividades da fase, o
que dever fazer com que os revisores sugiram mudanas nos artefatos da
respectiva fase e do ciclo em questo. A necessidade por tcnicas de inspeo
adaptadas ao FILM tambm originou o trabalho do acadmico Zanotto (2001), o
qual permitiu os primeiros debates em torno de um mdulo de inspeo para a
ferramenta CASE FILM.

17

Você também pode gostar