Modelagem de Processos

Autor: Prof. Dr. Ivanir Costa Colaboradores: Prof. Roberto Macias Profa. Elisngela Mnaco de Moraes Prof. Emanuel Augusto Severino de Matos

Professor conteudista: Dr. Ivanir Costa Doutor em Engenharia de Produo pela Escola Politcnica da Universidade de So Paulo (USP, 2003) e mestre em Engenharia de Produo pela Universidade Paulista (UNIP), ps-graduado em Sistemas de Informao pela UNIP, graduado em Fsica pela USP. Professor titular do programa de mestrado e doutorado da UNIP em Engenharia de Produo, onde realiza orientao para alunos doutorandos, mestrandos e da iniciao cientfica na graduao. Professor da EAD na UNIP, nas disciplinas de Qualidade de Software e Sistemas de Informao. Orientador de alunos de mestrado do IPT (Instituto de Pesquisas Tecnolgicas) da USP, professor do curso Gesto da Tecnologia da Informao, MBA da FIA/FEA. Possui dezenas de publicaes na rea de Engenharia de Produo e Tecnologia da Informao no Brasil e no exterior. consultor h mais de 30 anos em Tecnologia da Informao, com nfase em Engenharia de Software e Qualidade de Software, atuando principalmente nos seguintes temas: desenvolvimento de software, metodologia de desenvolvimento, mtricas de software, mtodos geis, produo de software, qualidade de software e governana de TI.

Dados Internacionais de Catalogao na Publicao (CIP)

C837m Costa, Ivanir Modelagem de processos / Ivanir Costa. So Paulo: Editora Sol, 2012. 144 p., il. Notas: este volume est publicado nos Cadernos de Estudos e Pesquisas da UNIP, Srie Didtica, ano XVII, n. 2-066/12, ISSN 1517-9230. 1. Tecnologia da informao. 2. Modelagem de processos. 3. Modelagem comportamental. I. Ttulo. CDU 65.011.56

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou quaisquer meios (eletrnico, incluindo fotocpia e gravao) ou arquivada em qualquer sistema ou banco de dados sem permisso escrita da Universidade Paulista.

Prof. Dr. Joo Carlos Di Genio

Reitor

Prof. Fbio Romeu de Carvalho

Vice-Reitor de Planejamento, Administrao e Finanas

Profa. Melnia Dalla Torre

Vice-Reitora de Unidades Universitrias

Prof. Dr. Yugo Okida

Vice-Reitor de Ps-Graduao e Pesquisa

Profa. Dra. Marlia Ancona-Lopez

Vice-Reitora de Graduao

Unip Interativa EaD

Profa. Elisabete Brihy Prof. Marcelo Souza Profa. Melissa Larrabure

Material Didtico EaD

Comisso editorial: Dra. Anglica L. Carlini (UNIP) Dr. Cid Santos Gesteira (UFBA) Dra. Divane Alves da Silva (UNIP) Dr. Ivan Dias da Motta (CESUMAR) Dra. Ktia Mosorov Alonso (UFMT) Dra. Valria de Carvalho (UNIP) Apoio: Profa. Cludia Regina Baptista EaD Profa. Betisa Malaman Comisso de Qualificao e Avaliao de Cursos Projeto grfico: Prof. Alexandre Ponzetto Reviso: Virgnia Bilatto Amanda Casale

Sumrio
Modelagem de Processos
APRESENTAO ......................................................................................................................................................7 INTRODUO ...........................................................................................................................................................7
Unidade I

1 A LINGUAGEM UNIFICADA DE MODELOS ..............................................................................................11 1.1 Introduo ................................................................................................................................................11 1.2 Motivao para o uso de modelos ................................................................................................ 12 1.3 Princpios da modelagem de software ........................................................................................ 14 1.4 Modelagem e orientao a objetos .............................................................................................. 15 1.5 Por que usar a orientao a objetos?........................................................................................... 16 1.6 Conceitos bsicos da orientao a objetos................................................................................ 22 2 A LINGUAGEM UNIFICADA DE MODELOS (UML)................................................................................ 28 2.1Introduo ................................................................................................................................................ 28 2.2 A UML e o Processo Unificado ........................................................................................................ 32
2.2.1 Engenharia de software e processos de software .....................................................................33 2.2.2 Os processos denominados de geis ............................................................................................... 37 2.2.3 O Processo Unificado UP ................................................................................................................. 37

Unidade II

3 MODELO CONCEITUAL DA UML................................................................................................................. 43 3.1 Introduo ............................................................................................................................................... 43 3.2 Viso geral da UML .............................................................................................................................. 43 3.3 Arquitetura da UML............................................................................................................................. 44 3.4 Modelagem estrutural........................................................................................................................ 45
3.4.1 Classes de objetos ................................................................................................................................... 45 3.4.2 Relacionamentos entre classes de objetos/instncias ............................................................. 46 3.4.3 Mecanismos comuns ............................................................................................................................. 46 3.4.4 Diagramas da UML ................................................................................................................................. 47

4 DIAGRAMA DE CLASSES DE OBJETOS DA UML ................................................................................... 51 4.1 Introduo ............................................................................................................................................... 51 4.2 Associao ............................................................................................................................................... 53 4.3 Papis em associao.......................................................................................................................... 55 4.4 Classe de associao ........................................................................................................................... 56 4.5 Agregao e composio .................................................................................................................. 58 4.6 Generalizao/especializao .......................................................................................................... 59 4.7 Herana .................................................................................................................................................... 60 4.8 Conceitos avanados envolvendo classes .................................................................................. 63
4.8.1 Herana mltipla .................................................................................................................................... 63 4.8.2 Classes abstratas ..................................................................................................................................... 65

4.9 Estudo de caso aplicando modelo de classes ........................................................................... 68

4.9.1 Descrio do sistema ............................................................................................................................. 68 4.9.2 Requisitos do sistema ........................................................................................................................... 69 4.9.3 Modelo de classe do sistema ............................................................................................................. 70

4.8.3 Polimorfismo (ocultamento de informaes) ............................................................................. 66 4.8.4 Interfaces tipos e papis ...................................................................................................................... 67 4.8.5 Pacotes lgicos ........................................................................................................................................ 67 4.8.6 Objetivos do diagrama de classes .................................................................................................... 68

Unidade III

5 MODELAGEM COMPORTAMENTAL (MODELO DINMICO) ............................................................. 76 5.1 Introduo ............................................................................................................................................... 76 5.2 Modelo de casos de uso .................................................................................................................... 77

5.2.1 Diagramas de caso de uso................................................................................................................... 77

6 OUTROS MODELOS COMPORTAMENTAIS DA UML ............................................................................ 91 6.1 Introduo ............................................................................................................................................... 91 6.2 Diagrama de atividades ..................................................................................................................... 92 6.3 Diagrama de sequncia...................................................................................................................... 93
6.3.1 Linha de vida............................................................................................................................................. 95 6.3.2 Ativao ...................................................................................................................................................... 95 6.3.3 Autodelegao ......................................................................................................................................... 95 6.3.4 Mensagem ................................................................................................................................................. 95

6.4 Diagramas de estado (mquina de estado) ............................................................................... 96

6.4.1 Estado .......................................................................................................................................................... 96 6.4.2 Notaes..................................................................................................................................................... 96 6.4.3 Evento.......................................................................................................................................................... 97 6.4.4 Transio..................................................................................................................................................... 98

Unidade IV

7 MODELAGEM DA ARQUITETURA DE NEGCIO .................................................................................103 7.1 Introduo .............................................................................................................................................103 7.2 Modelagem de negcio ...................................................................................................................104
7.2.1 Conceitos de negcio ..........................................................................................................................105 7.2.2 Extenso de negcio da UML........................................................................................................... 110 7.2.3 Vises de modelos de negcio ........................................................................................................114 7.4.1 Processo de desenvolvimento de software ................................................................................116 7.4.2 Arquitetura de negcio e arquitetura de software .................................................................117

7.3 OCL e sua utilizao na modelagem de processo de negcio ......................................... 114 7.4 Integrao com o desenvolvimento de software.................................................................. 116 8 A MODELAGEM DE PROCESSOS DE NEGCIO .................................................................................. 119 8.1 Viso Erikson e Penker ...................................................................................................................... 119 8.2 A modelagem de processos de negcio com a BPM ...........................................................122
8.2.1 Objetos de fluxo ................................................................................................................................... 125 8.2.2 Objetos de conexo............................................................................................................................. 127 8.2.3 Raias (Swimlanes) ................................................................................................................................ 129 8.2.4 Artefatos...................................................................................................................................................131

8.3 Concluso do BPMN .........................................................................................................................133

APRESENTAO

O objetivo da disciplina Modelagem de Processos apresentar e conceituar a importncia de modelos no desenvolvimento de sistemas de informao. Nela, os alunos tero condies de entender, analisar, desenhar e descrever os principais e mais importantes modelos de desenvolvimento de software, utilizando a linguagem de modelagem UML (Unified Modeling Language), tanto os modelos estticos como os modelos dinmicos. A disciplina tambm apresenta os conceitos e simbologias envolvidos com a modelagem das reas de negcio, bem como os mapeamentos de negcios por meio da UML e da moderna linguagem de modelagem de negcios BPMN (Business Process Modeling Notation).
INTRODUO

Entre os autores e especialistas envolvidos com os processos de desenvolvimento de software, existe a crena de que, de algum modo, a modelagem pode ser aplicada para facilitar a nossa vida. Desde a dcada de 1970, os autores especializados em software vm propondo processos ou metodologias de desenvolvimento de sistemas que, apesar de utilizarem abordagens diferentes, sempre possuem em seu bojo o uso de modelos visuais e descritivos. Isso fundamentado no fato de que os modelos visuais permitem o entendimento do mesmo assunto por pessoas com conhecimentos e perfis diferentes. A importncia desse entendimento torna-se primordial, j que no processo de software temos a participao de pessoas de diversas reas de uma organizao, indo do usurio final de uma rea de negcio at o especialista em software e hardware da rea de TI. Todavia, ao longo desse tempo, a modelagem de software vem sendo criticada devido percepo de que a modelagem uma atividade que precede o desenvolvimento real e que tem como foco a documentao. Isto , para muitos especialistas, no se deve privilegiar o desenho ao prprio desenvolvimento. Essas crticas vieram principalmente dos defensores dos mtodos geis, que privilegiam o cdigo em vez da documentao. Outros autores, entretanto, insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento central importante. Quando os modelos so considerados parte das atividades do processo de desenvolvimento e geram artefatos de primeira classe, os desenvolvedores geram menos cdigo convencional, uma vez que abstraes de aplicativo mais poderosas podem ser empregadas. Dessa forma, quando os modelos abrangem as atividades de desenvolvimento, a comunicao entre as pessoas envolvidas pode ser otimizada e a capacidade de rastreamento ativada no ciclo de vida em qualquer direo. A otimizao tambm vem do fato de que os modelos podem ser fontes de reuso tanto dos objetos criados como das descries que os envolvem. Acredita-se que tornar a modelagem uma corrente predominante dentro da rea de desenvolvimento de sistemas de uma organizao pode levar a uma economia de recursos e, com isso, aumentar a 7

abrangncia de automao no atendimento das necessidades de uma empresa. A automao do processo de desenvolvimento com o uso de geradores de sistemas a partir de modelos construdos tende a ser uma realidade a mdio e longo prazos no processo de software. Pode-se citar, dentro dessa realidade, a Microsoft, que emitiu um documento denominado de Estratgia de modelagem em 2005, que aborda o desenvolvimento dirigido por modelo dentro de uma iniciativa chamada Fbricas de Software. Existem diversas empresas, rgos e grupos que adotam e propem o uso de modelos no desenvolvimento de software. Entre eles, pode-se citar o Object Management Group (OMG), que adotou a linguagem para a modelagem de produtos de software denominada de UML em novembro de 1997. Essa adoo ocorreu em um evento histrico e marcante, pois assinalou a aceitao de uma linguagem padronizada de modelagem de sistemas baseada nas melhores prticas atuais para a anlise, o projeto e a construo de software orientado a objetos. A UML, tema central desta disciplina, a primeira notao que atingiu o consenso entre a maioria dos profissionais, vendedores e acadmicos como o padro real para expressar um domnio comercial da soluo de software. Entre os autores da UML, temos o americano Grady Booch, que diz que a modelagem deve atingir quatro objetivos para se tornar efetiva em um ambiente de desenvolvimento de software: 1. Ajudar a equipe de projeto a visualizar um sistema como ele ou pretende ser. 2. Ajudar a especificar a estrutura ou o comportamento do sistema. 3. Proporcionar um modelo que sirva de guia na construo do sistema. 4. Documentar as decises tomadas pela equipe de desenvolvimento de projeto. A UML precisa desses objetivos para ser efetiva (REED Jr., 2000). Ela apresentada tanto nos seus modelos estticos como nos modelos dinmicos que mostram as estruturas e os comportamentos dos objetos envolvidos em uma determinada aplicao ou software nos modelos da tecnologia orientada a objetos. Na atualidade, outra rea de interesse e importante na construo de sistemas fundamentais a de processos de negcio, que se prope a mostrar as atividades previamente estabelecidas nas reas de negcio e determinar a forma como o trabalho realizado numa organizao. Essas atividades de negcio constituem um conjunto de aes relacionadas entre si de forma lgica e coerente, a fim de promover uma sada favorvel organizao, em nveis interno e externo. Uma boa modelagem dos processos de negcio leva implementao de um sistema de informao bemestruturado. 8

A disciplina aborda os conceitos de modelos, a importncia da modelagem de sistemas de informao, a tecnologia orientada a objetos e as modelagens UML e BPM no processo de desenvolvimento de software.

ModelageM de Processos

Unidade I
1 A LINgUAgEM UNIfICADA DE MODELOS 1.1 Introduo

Existe uma crena, entre os envolvidos no desenvolvimento de software, de que, de algum modo, a modelagem pode ser aplicada para facilitar as suas vidas. Todavia, ao longo do tempo, a modelagem de software vem sendo criticada devido percepo de que uma atividade que precede o desenvolvimento real e que tem como foco a documentao. Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento central importante e no uma atividade focada principalmente em documentao. Quando os modelos so considerados artefatos de desenvolvimento de primeira classe, os desenvolvedores geram menos cdigo convencional, uma vez que abstraes de aplicativo mais poderosas podem ser empregadas. Assim, o desenvolvimento dirigido por modelo inerentemente mais produtivo e gil. Alm disso, outros participantes no desenvolvimento como analistas de negcios, arquitetos e gerentes de projetos, iro reconhecer a modelagem como o que adiciona valor s tarefas pelas quais so responsveis. Quando os modelos abrangem as atividades de desenvolvimento e em tempo de execuo dessa maneira, a comunicao entre as pessoas pode ser otimizada, e a capacidade de rastreamento ativada no ciclo de vida em qualquer direo. Acredita-se que, ao tornar a modelagem uma corrente predominante, pode-se alterar a economia do desenvolvimento de softwares e garantir que os sistemas de software atendam s necessidades de uma empresa. De acordo com a Microsoft, em seu documento denominado de Estratgia de modelagem, de 2005, essa abordagem do desenvolvimento dirigido por modelo parte de uma iniciativa chamada Fbricas de software.

11

Unidade I

Saiba mais Vale a pena ler o artigo de maio de 2005, disponvel no site <http://msdn.microsoft.com/pt-br/library/ms379623(v=vs.80).aspx>, que discute a estratgia de desenvolvimento da Microsoft, dirigido por modelos com uma srie de perguntas e respostas relativas a esses tpicos e interesses. Esse artigo basicamente pergunta e responde: por que modelagem? Como as DSLs so usadas no desenvolvimento dirigido por modelo? E quanto UML? E quanto MDA? O que so fbricas de software?
1.2 Motivao para o uso de modelos

Ainda de acordo com a Microsoft, um modelo deve ser um artefato de primeira classe em um projeto, no apenas uma documentao aguardando para se tornar desatualizada. O autor Senge (1990): 1. Define que modelos so mentais, so pressuspostos profundamente arraigados, generalizaes, ou mesmo imagens que influenciam a forma de ver o mundo e de nele agir. Muitas vezes, no estamos conscientes de nossos modelos mentais ou de seus efeitos sobre nosso comportamento. 2. Afirma que o trabalho com modelos mentais inclui tambm a capacidade de realizar conversas ricas em aprendizados, que equilibrem indagao e argumentao, em que as pessoas exponham de forma eficaz seus prprios pensamentos e estejam abertas influncia dos outros. 3. Os modelos possuem uma sintaxe precisa, geralmente so melhores editados e visualizados com uma ferramenta grfica e contm semnticas que determinam como conceitos especficos de domnio mapeiam para outros artefatos de implementao, como: cdigo, estruturas de projeto e arquivos de configurao. 4. Dessa maneira, um modelo se parece muito com um arquivo de cdigo-fonte, e os mecanismos que o sincronizam com outros artefatos de implementao so muito semelhantes a compiladores. 5. Um modelo representa um conjunto de abstraes que d suporte a um desenvolvedor em um aspecto de desenvolvimento bem definido. 6. Como os modelos podem abstrair e agregar informaes de uma srie de artefatos, podem dar suporte de modo mais rpido a verificaes de consistncia e outras formas de anlise. 12

ModelageM de Processos

Observao Um modelo de conectividade de aplicativos, por exemplo, poder suportar validao de protocolo de contrato, anlise de segurana ou anlise de desempenho. Um modelo uma representao ou interpretao simplificada da realidade, ou uma interpretao de um fragmento de um sistema segundo uma estrutura de conceitos. Um modelo apresenta apenas uma viso ou cenrio de um fragmento do todo. Normalmente, para estudar um determinado fenmeno complexo, criam-se vrios modelos. Observao Por exemplo, pode-se citar obras da Engenharia civil, tais como, uma grande obra hidrulica, uma ampliao de uma praia artificial ou mesmo uma usina hidreltrica, no so projetadas sem estudos detalhados em vrios tipos de modelos matemticos de diversas categorias e tipos, como modelos de hidrologia, hidrulica e mecnica dos solos. Modelagem tambm pode ser vista como a arte de criar moldes tanto em fundio (nesse caso, os de areia), como em calados e em confeco de peas para o vesturio. No caso dessa ltima, o molde obtido por uma das trs tcnicas bsicas: moulage, modelagem geomtrica ou simples cpia. Segundo os autores Huckvale e Ould (1993, apud BRANCO, 2007), um modelo aplicado a processos oferece: Um meio para discusso: o modelo de processos ajuda a situar as questes relevantes ao permitir a abstrao do mundo real, salientando os objetos e relacionamentos que so de interesse e ignorando detalhes que possam contribuir para aumentar a complexidade. Um meio para comunicao: permite que outras pessoas, que no as envolvidas no desenvolvimento do modelo, possam utiliz-lo como base para a sua implementao ou para a concepo de novos modelos. Uma base para anlise: a anlise de um modelo pode revelar os pontos fortes e fracos do processo, com especial relevncia para os fracos, como aes que acrescentam pouco valor ou so potenciais focos de problemas. A anlise por simulao e animao do modelo permite, ainda, estudar os efeitos que possveis alteraes podem causar em um dado processo. 13

Unidade I
Uma base para concepo de novos processos. Uma base para melhoria contnua: as sugestes para a mudana podem ser expressas em termos de alteraes ao modelo e da sua anlise, sendo possvel ainda sugerir mtricas para avaliar o seu desempenho. Uma base para controle: quando suficientemente formal para ser automatizado, o modelo pode ser utilizado para controlar a execuo do sistema modelado, como em um sistema de gesto de Workflow. Alm de garantir o correto funcionamento, permite efetuar medies quanto ao desempenho do processo.
1.3 Princpios da modelagem de software

A modelagem de sistemas de informao (software) a atividade de construir modelos que expliquem as caractersticas ou o comportamento de um software ou aplicativo, ou de um sistema de software. Na construo do software, os modelos podem ser usados na identificao das caractersticas e funcionalidades que o esse dever prover e no planejamento de sua construo. Frequentemente, a modelagem de software usa algum tipo de notao grfica e apoiada pelo uso de ferramentas de apoio denominadas de ferramentas Case. Ferramentas Case (Computer-Aided Software Engineering) uma classificao que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de software, desde anlise de requisitos e modelagem at programao e testes. Podem ser consideradas como ferramentas automatizadas que tm como objetivo auxiliar o desenvolvedor de sistemas em uma ou vrias etapas do ciclo de desenvolvimento de software. A modelagem de software normalmente implica a construo de modelos grficos que simbolizam os artefatos dos componentes de software utilizados e os seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (no orientados a objeto) por meio de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usa a linguagem grfica de modelos UML. Observao Vale a pena, para quem ainda no conhece ou utilizou uma ferramenta Case, fazer download de uma ferramenta free, tais como a ferramenta JUDE ou a ferramenta Umbrello UML, e com elas verificar 14

ModelageM de Processos
uma srie de propriedades e facilidades que ajudam na documentao, facilitam a comunicao e ainda aumentam de forma considervel a produtividade dos desenvolvedores de software. Algumas so to sofisticadas que chegam a gerar cdigo diretamente dos modelos construdos.
1.4 Modelagem e orientao a objetos

De acordo com vrios autores, h muito tempo busca-se um padro de construo de software orientado a objetos e sua representao, semelhana da planta utilizada por outras reas da Engenharia, tal como a planta de uma casa ou arquitetura de um prdio da Engenharia Civil. O enfoque tradicional de modelagem para a construo de sistemas de informao baseia-se na compreenso desse sistema como um conjunto de programas que, por sua vez, executam processos sobre dados. O enfoque de modelagem por objetos v o mundo como uma coletnea de objetos que interagem entre si e apresentam caractersticas prprias, que so representadas pelos seus atributos (dados) e operaes (processos) (FURLAN, 1998). A figura 1 mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.

Programa Processos Dados

Classe Atributos

Operaes

Foco em sistema

Foco em objeto

Figura 1 Sistema vs. objeto

Um programa, no sentido tradicional agora, um conjunto de objetos que se relacionam para executar as funcionalidades ou processos do sistema aplicativo. Ento, o programa representado por classes; os processos, por operaes ou mtodos; e os dados, por atributos dos objetos. Essa mudana de enfoque se justifica devido ao fato de que os objetos existem na natureza muito antes de o homem criar os computadores e os seus programas de software. 15

Unidade I
Carros, equipamentos, pessoas, bancos etc. apresentam caractersticas prprias que podem ser representadas pelos seus atributos e pelos seus comportamentos no mundo real. Furlan (1998) informa que essa abordagem oferece como principais benefcios: manter a modelagem do sistema e, em decorrncia, sua automao o mais prximo possvel de uma viso conceitual do mundo real; servir de base decomposio e modelagem do sistema nos dados, que o elemento mais estvel de todos aqueles que compem um sistema de informao; oferecer maior tranparncia na passagem de modelagem para a construo por meio da introduo de detalhes, no requerendo uma reorganizao do modelo. Lembrete Embora o termo orientao a objetos tenha sido usado de vrias formas distintas, deveria sempre sugerir uma associao entre coisas do mundo real e trechos de programas de computador ou objetos. De uma maneira mais informal, objeto pode ser visto ou entendido como uma entidade independente, assncrona e concorrente. Diz-se que um objeto sabe coisas, isto , armazena dados; objeto realiza trabalho, isto , encapsula servios; objeto colabora com outros objetos por meio de troca de mensagens, para executar as funes finais do sistema, sendo modelado. James Rumbaugh (1994) define orientao a objetos como:
[...] uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental o objeto que combina estrutura e comportamento em uma nica entidade (RUMBAUGH, 1994). 1.5 Por que usar a orientao a objetos?

Dentre as vrias razes pode-se citar: Inconsistncia na viso dos modelos: Diferentemente das outras tecnologias de desenvolvimento, o mesmo conjunto de modelos na OO utilizado em todo o ciclo de desenvolvimento. 16

ModelageM de Processos
Os objetos so: Descobertos na fase de anlise de sistemas para representar os requisitos do usurio. Alterado na fase de projeto para incorporar as caractersticas do ambiente operacional do sistema. E finalmente utilizado na fase de construo para subsidiar a implementao nas linguagens OO e nos gerenciadores de banco de dados. Objetos definidos na anlise tm representao direta no cdigo, evidenciando a relao entre a definio do problema e a sua implementao. Melhor abstrao do domnio do problema: A OO mantm uma forte coeso entre a estrutura e o comportamento dos objetos, e essa a maneira como a realidade se manifesta. Facilidade para reusabilidade: A grande procura da Engenharia de software nos ltimos anos foi uma forma, ou um mtodo que possibilitasse o reuso de cdigo, prometida por todos, mas nunca alcanado. A OO, com a implementao do conceito de generalizao e especializao, a partir da herana, possibilitam isto. Melhor suporte integridade: Interao entre os componentes OO restrita a poucas interfaces que so bem definidas. A nica forma de comunicao entre os objetos se d por meio de troca de mensagens. Suporte decorrencial concorrncia: A sincronizao de suas partes pode ser mostrada por meio de diagramas e da passagem de mensagens entre os objetos do sistema. Uso de herana: Identifica e aproveita os pontos comuns dos dados e servios (operaes, rotinas, mtodos). Herana sinnimo de reusabilidade. A orientao a objetos oferece modularidade de seus elementos, podendo-se tomar um subconjunto existente e integr-lo de uma maneira diferente em outra parte do sistema. 17

Unidade I
Afirma-se que, dessa forma, uma aplicao (sistema) no universo de objetos consiste de um conjunto de blocos de construo autocontidos e predefinidos que podem ser localizados, reparados ou substitudos. Lembrete Uma das coisas mais importantes da modelagem orientada a objetos est na reusabilidade. As tcnicas de orientao a objetos permitem reutilizar muito mais do que o cdigo. Com os modelos orientados a objetos, pode-se reutilizar requisitos, anlise, projeto, planejamento de testes, interfaces de usurios e arquiteturas. Praticamente todos os componentes do ciclo de vida da Engenharia de software podem ser encapsulados como objetos reusveis (YOURDON, 1998). A essncia da anlise e do desenho orientados a objetos de uma aplicao de software a descrio de comportamentos. Modelos dinmicos so utilizados para implementar os comportamentos que atendem s necessidades e metas do usurio. As disciplinas de anlise e de desenho com objetos apresentam tcnicas utilizadas para separar e encapsular os comportamentos das aplicaes de software. Os diferentes modelos elaborados durante a anlise e o desenho so utilizados de acordo com a sua natureza: Modelo dinmico: descreve os comportamentos exibidos pelo computador, quando esse realiza os servios solicitados pelo usurio. Modelo esttico: descreve a estrutura lgica do computador, de modo que ele se comporte de maneira adequada, e gerencia as dependncias entre as diversas partes lgicas do computador. A modelagem orientada a objetos inicia-se com a anlise orientada a objetos (AOO), que estabelece o comportamento fundamental de um sistema, comportamento que pode ser mantido independentemente de como o sistema ser construdo. Na anlise OO, so construdos modelos formais de um sistema de software proposto (semelhante aos modelos em escala de um prdio feitos por um arquiteto ou engenheiro civil), que capturam os requisitos essenciais do sistema. Esse modelo deve ser documentado em uma notao ou linguagem simblica, de preferncia conhecida e testada no mercado de software. Um modelo de AOO retrata objetos que representam um domnio de aplicao especfico, juntamente com diversos relacionamentos estruturais e de comunicao. 18

ModelageM de Processos
De acordo com Yourdon (1998), o modelo de AOO serve para dois propsitos: primeiro, para formalizar a viso do mundo real dentro do qual o sistema de software ser construdo; segundo, estabelece a maneira pela qual um dado conjunto de objetos colabora para executar o trabalho do sistema de software que est sendo especificado. Na abordagem AOO, de Edgard Yourdon, existem cinco camadas ou vises, conforme a figura 2, que permitem visualiz-lo de perspectivas distintas.
Nome da camada Classes e objetos Smbolos Bordas da classe Borda da instncia (objeto) Atributos Atributos Conexo entre objetos Mensagens Servios

Servios

Estruturas

Assuntos

Assuntos

Figura 2 Estrutura de um modelo de AOO

A camada de classes e objetos apresenta os blocos bsicos de construo do sistema proposto. Os objetos so abstraes de conceitos do domnio de aplicao do mundo real. O corao de qualquer AOO o processo denominado de modelagem de informaes. Na modelagem AOO, os autores consideram como parte difcil do problema estabelecer o que so as coisas do mundo real. No caso de mtodos orientados a objetos, tem sido dada mais nfase na modelagem de informaes como um procedimento formal dentro do processo de Engenharia de software (YOURDON, 1998). A figura 3 apresenta um exemplo de aplicao da modelagem AOO com o uso da notao de Edward Yourdon. Sero representadas as entidades envolvidas em um domnio de prestao de servios por assinatura, como uma assinatura de tv fechada, uma assinatura telefnica etc. O exemplo apresenta somente alguns atributos e alguns servios de um domnio de aplicao qualquer. 19

Unidade I

Assinante Id_assinante Det_assinante Id_endereco Entrar_assinante Informar_endereco 1 1

Assinatura Id_assinatura Estado_assinatura Detalhes_assinatura

Entrar_assinatura

Figura 3 Exemplo de uma aplicao da AOO

Aps a modelagem completa do sistema com todas as entidades, seus atributos, seus servios e suas estruturas comportamentais definidas (relacionamentos), deve ser construdo o Projeto Orientado a Objetos (POO), como uma extenso do modelo AOO. Na proposta de Edward Yourdon, o modelo POO contm as mesmas cinco camadas e usa a mesma notao do modelo AOO, mas estendido para conter: componente de interao humana (interface homem x mquina), componente de gerenciamento de tarefas e componente de gerenciamento de dados. O componente de interao humana modela a tecnologia de interface que ser usada para uma implementao especfica do sistema. O componente de gerenciamento de tarefas especifica os itens operacionais que sero estabelecidos para implementar o sistema. Finalmente, o componente de gerenciamento de dados define aqueles objetos necessrios para interfacear com a tecnologia de banco de dados que est sendo usada. Alm da abordagem de Edward Yourdon, outros mtodos e modelagens orientadas a objetos apareceram desde a dcada de 1970 at 1995. A seguir, algumas das iniciativas desse perodo: Sally Shlaer e Steve Mellor escreveram livros sobre anlise e desenho orientado a objetos no final da dcada de 1980 e incio da dcada de 1990. Jim Odell e James Martin basearam seus enfoques na longa experincia adquirida por ambos no uso e divulgao da Engenharia da informao. Em 1994 e 1996, lanaram os livros mais conceituais da poca. Peter Coad e Ed Yourdon escreveram livros que propuseram um enfoque de desenho recursivo em 1997, propondo a AOO e o POO. Jim Rumbaugh liderou uma equipe de pesquisadores nos laboratrios da General Electric, que o levou ao livro sobre mtodos chamados OMT (Object Modeling Technique) em 1991. 20

ModelageM de Processos
Grady Booch desenvolveu um mtodo na Rational Software para anlise de sistemas intensivos em Engenharia e que foram apresentados em seus livros publicados em 1994 e 1995. Ivar Jacobson produziu seus livros a partir de sua experincia em sistemas na Ericson e desenvolveu o mtodo OOSE (Object-Oriented Software Engineering), que se tornou a base do processo UP e do processo RUP. Toda a proposta est na procura da independncia de tecnologia e, portanto, a busca da reusabilidade. Se um dia for necessrio trocar a tecnologia envolvida com as interfaces GUI por outra tecnologia mais atual, seria necessrio substituir apenas o componente de interao humana. A histria da OO inicia-se no final da dcada de 1960, com a linguagem Simula, que foi projetada por Kristen Nygaard e Ole-Johan Dahl no centro de computao noruegus, em Oslo. No incio da dcada de 1970, os cientistas da computao Edsger Dijkstra e David Lorge Parnas trabalharam no conceito de programao modular, que um importante elemento da programao orientada a objetos nos dias de hoje. Tambm na dcada de 1970, surge a linguagem Smalltalk: Uma linguagem de programao orientada a objeto fracamente tipada. Em Smalltalk, tudo objeto: os nmeros, as classes, os mtodos, os blocos de cdigo etc. No h tipos primitivos, ao contrrio de outras linguagens orientadas a objeto. Strings, nmeros e caracteres so implementados como classes em Smalltalk, por isso essa linguagem considerada puramente orientada a objetos. Tecnicamente, todo elemento de Smalltalk um objeto de primeira ordem. Os programadores definem classes de objetos em suas aplicaes para imitar (ou simular) o mundo real. Essas classes de objeto so organizadas hierarquicamente, de modo que seja possvel fazer novos objetos com caractersticas de outros objetos, com poucas mudanas. A linguagem Smalltalk foi desenvolvida por Adele Goldberg e Alan C. Kay. No final da dcada de 1970, surge a linguagem ADA: Ada uma linguagem de programao estruturada, de tipagem esttica, uma linguagem imperativa, orientada a objetos, e uma linguagem de alto nvel, originada da linguagem Pascal e de outras linguagens. Foi originalmente produzida por uma equipe liderada por Jean Ichbiah, da Companhia Honeywell Bull, contratada pelo Departamento de Defesa dos Estados Unidos durante a dcada de 1970, com o intuito de substituir as centenas de linguagem de programao usadas pelo DoD. 21

Unidade I
Ada uma aplicao com compiladores validados para uso confivel em misses crticas, tais como softwares de aviao. Normatizada internacionalmente pela ISO, sua verso mais atual de 2005. Em meados de 1980, o cientista da computao dinamarqus Bjarne Stroustrup criou a linguagem C++ e, dessa forma, conhecido como o pai da linguagem de programao C++. Stroustrup tambm escreveu o que muitos consideram a obra padro de introduo linguagem, A linguagem de programao C++, que se encontra na terceira edio. A obra possui revista para refletir a evoluo da linguagem e o trabalho do comit de padres de C++, e inspirou as novas linguagens, tais como a linguagem Java e o C#.

Saiba mais Vale a pena ler o livro de Bertrand Meyer cujo ttulo Object-oriented Software Construction, que se tornou um clssico na rea da tecnologia OO. O livro, apesar de ser de 1988, j apresenta um conjunto de conceitos sobre a reusabilidade, tcnicas de projeto, programao orientada a objetos e a aplicao das tcnicas OO em outros ambientes de desenvolvimento.
1.6 Conceitos bsicos da orientao a objetos

Os objetos podem ser vistos como blocos de construo que, combinados por meio de tcnicas apropriadas, produzem um sistema.
Blocos de construo Blocos de rotinas/mtodos

Anlise/ Projeto/ Construo

Tcnicas adequadas de anlise e projeto

Sistemas Figura 4 Objetos vistos como blocos de construo

22

ModelageM de Processos
A tecnologia OO apresenta diversos conceitos fundamentais para seu entendimento e aplicao (FURLAN, 1998): Objeto: um objeto uma ocorrncia especfica (instncia) de uma classe e similar a uma entidade de dados do modelo E x R ou a uma tabela relacional, somente at o ponto em que representa uma coleo de dados relacionados com um tema em comum. Uma pessoa um objeto, um veculo um objeto, um documento um objeto. Outros conceitos sobre objeto: Objeto uma bolha de inteligncia que sabe agir numa determinada situao (Steve Jobs). Objeto alguma coisa que faz sentido no contexto de uma aplicao, dependente do nvel de abstrao do desenvolvedor do sistema. Objetos so a base da tecnologia orientada a objetos. Objetos podem representar coisas do mundo real: carro, gato, mquinas etc. Entidades conceituais: conta bancria, compras, pedido etc. Coisas visuais: polgonos, pontos, retas, letras, formulrios etc. Objeto um conceito, uma abstrao, algo com limites ntidos e significado com relao ao problema em causa (James Rumbaugh). Abstrao: abstrao consiste na seleo que se faz de alguns aspectos do problema em questo, ignorando-se outros aspectos. Qualquer objeto real pode ser abstrado para filtrar seu estado e comportamento. O estado de um objeto determinado pelo seu conjunto de atributos (dados), e seu comportamento definido pelos seus servios (mtodos). Exemplos de objetos de informtica: label, boto, caixa de texto, de dilogo etc. Exemplos de objetos de negcio: funcionrio, departamento, produto etc. Mensagem: objetos se comunicam a partir da troca de mensagens, isto , um sinal enviado de um objeto a outro, requisitando um servio por meio da execuo de uma operao do objeto chamado. A interface lgica entre objetos feita a partir da passagem de mensagens. 23

Unidade I
As mensagens ocorrem apenas entre objetos que possuem uma associao. Todo o processamento da OO ativado por uma implementao de mensagens que refora o conceito de baixo acoplamento em sistemas orientados a objetos. A recepo de uma mensagem causa a invocao de uma operao no recebedor (objeto alvo). Esse executa o mtodo da classe que corresponde quela operao. Uma mensagem pode tomar vrias formas: procedure, passagem de sinal entre threads ativas, acionamento especfico de um evento etc. Um determinado objeto, recebendo uma mensagem, executar uma ao especfica como resposta, alterando seu estado interno, enviando mensagens a outros objetos, criando novos objetos etc.
Objeto o1 Objeto cliente para o2 Objeto o3 Objeto servidor para o2

Mensagem de o1 para o2

Objeto o2 Objeto cliente para o3 01 aeronave Objeto aeronave aterrisar Flap ajustado Flap 1 ngulo 02 Flap ajustar ngulo Nome da mensagem Objeto Flap

Figura 5 Troca de mensagens entre objetos

A mensagem indica uma solicitao de O1 para O2, coloque o flap num ngulo x! Essa uma mensagem imperativa. O objeto 02 responde que est tudo ok. Na OO, os parmetros de chamada e resposta tambm so chamados objetos (tudo objeto). 24

ModelageM de Processos
Polimorfismo: o poder que uma operao de um objeto tem de assumir vrios comportamentos dependendo da chamada recebida, tratando e devolvendo respostas especficas ao chamador. Exemplo: uma classe possui um atributo saldo que pode variar de acordo com o objeto chamador. Pode ser saldo do correntista, saldo da poupana, saldo do fundo de aes, saldo de renda fixa etc. Ento, a operao buscar_saldo vai buscar o saldo dependendo do tipo ou parmetro da chamada, tendo vrias lgicas diferentes para um mesmo comportamento denominado buscar_saldo. Classe: classe uma coleo de objetos que podem ser descritos com os mesmos atributos e as mesmas operaes. Representa uma idia ou um conceito simples e categoriza objetos que possuem propriedades similares, configurando-se em um modelo para a criao de novas instncias. uma abstrao das caractersticas comuns a um conjunto de objetos similares. A classe pode ser pensada como sendo um tipo abstrato de dados. Conjunto de objetos com propriedades semelhantes, mesmo comportamento (operaes, mtodos), mesmos relacionamentos com outros objetos e mesma semntica em um domnio de aplicao. como se fosse um molde para criao de objetos. A linguagem Java um conjunto de classes. Por exemplo: Panel, Label etc. Se o objeto O pertence classe C, dizemos que: O uma instncia de C; ou O um membro da classe C; ou O pertence a C. Quando queremos ser precisos e nos referirmos a uma coisa exata, usaremos instncia de objeto. Para nos referirmos a um grupo de coisas semelhantes, usaremos classe de objetos. Os objetos de uma classe compartilham um objetivo semntico comum, alm dos requisitos de atributos e comportamentos. 25

Unidade I
Classe Cavalo Classe Celeiro

Figura 6 Exemplo de classe de objetos

Embora um celeiro e um cavalo tenham ambos um preo e uma idade, podem pertencer a classes diferentes. Caso sejam vistos, no problema, apenas como bens contbeis, poderiam pertencer mesma classe. Herana: a capacidade de um novo objeto tomar atributos e operaes de um objeto existente, permitindo criar classes complexas sem repetir cdigo. A nova classe simplesmente herda seu nvel base de caractersticas de um antepassado na hierarquia de classe. O propsito principal do uso de herana construir estruturas que possam ser estendidas em muitas formas diferentes. Esse enfoque pragmtico pode-se completar considerando os propsitos de reusabilidade a vrios nveis e os propsitos de ordem conceitual. A reusabilidade uma das metas mais prezadas que os produtos de software pretendem atingir. O termo reusar tem o significado de poder usar um elemento numa situao diferente da original para o qual foi criado, reduzindo e simplificando esforos (MATICH e CARVALHO, 1992). A herana tem implicitamente um propsito de reusabilidade, j que proporciona uma forma de reaproveitar caractersticas capturadas por componentes, seja na forma de objetos, tipos ou classes. Atributo ou propriedade: caracterstica particular de uma ocorrncia da classe, por exemplo: o aluno possui nome, sexo, data de nascimento, nmero de registro, telefone etc. Caracterstica que um objeto possui. Exemplo: nome, cor, altura, data de nascimento etc. Conjunto de propriedades de um objeto que definem o seu estado. Propriedades estticas: mantm o mesmo valor durante toda a sua existncia (exemplo: data de nascimento de uma pessoa). Propriedades dinmicas: podem ter valores que variam com o passar do tempo (exemplo: salrio de um funcionrio). Encapsulamento: combinao de atributos e operaes em uma classe. Exemplo: classe aluno, com atributo nome e operao altera_nome_aluno. 26

ModelageM de Processos
a capacidade que possuem os objetos de incorporar tanto as estruturas de dados que os determinam, como as operaes aplicveis a essas estruturas em nico bloco de organizao e s permitir o acesso a elas por meio de mtodos determinados. Vantagens do encapsulamento: Esconder (ocultar) a complexidade do cdigo. No necessrio conhecer como a operao feita para poder utiliz-la, o cdigo oculto do usurio. Proteger os dados, permitindo o acesso a eles apenas a partir de mtodos, evita que seus dados sejam corrompidos por aplicaes externas. Generalizao: atributos e operaes comuns, compartilhados por classes em uma hierarquia pai-e-filho, ou superclasse e subclasses, ou classe pai e classes filho. Instncia de classe: uma ocorrncia especfica de uma classe. o mesmo que objeto. Jos Carlos Filho uma instncia da classe aluno, j que o Jos Carlos Filho aluno cadastrado no sistema acadmico da escola. Classes fabricam instncias sob requisio. Esse processo chamado instanciao.

Um objeto Aeronave Uma classe Instanciao Outro objeto

E outro objeto Figura 7 Instanciao

O projetista/programador cria a classe. Em tempo de execuo, a classe pode ser solicitada para criar novos objetos. Uma classe possui dados/atributos ou variveis (programao), servios/operaes ou mtodos (programao). Exemplo: quantidade de carros um atributo de classe da classe carro. Cada atributo de classe possui um nico valor para o conjunto de objetos da classe. 27

Unidade I
Uma instncia (um membro) de uma classe tambm possui: dados/atributos ou variveis de instncia e operaes/mtodos de instncia. Exemplo: cor, peso e ano de fabricao so atributos de instncia da classe carro. Cada atributo de instncia possui um valor para cada instncia de objeto. O nome de um atributo nico dentro de uma classe. O agrupamento de objetos em classes permite a abstrao de um problema. As definies comuns e as operaes de cada instncia so descritas somente uma vez na classe, e os objetos da classe podem beneficiar-se da reutilizao das definies armazenadas. Operaes: lgica contida em uma classe para designar-lhe um comportamento. Exemplo: calcular a idade de um aluno dada a sua data de nascimento. Operao uma funo ou transformao que pode ser aplicada a objetos ou por esses a uma classe em uma determinada situao. Exemplo: alterar sua cor, mostrar uma janela, debitar um valor, aceitar o crdito de um cliente. Todos os objetos da classe compartilham as mesmas operaes. Mtodo a implementao de uma operao para uma classe. O ato de invocar um mtodo tambm chamado de passar uma mensagem para o objeto. Toda classe possui um mtodo denominado construtor: atribui valores s propriedades de um objeto quando esse criado. o mtodo de inicializao de um objeto instanciado. Em Java o mtodo construtor possui sempre o mesmo nome da classe. Subclasse: caracterstica particular de uma classe. Exemplo: classe animal, subclasses gato, cachorro etc.
2 A LINgUAgEM UNIfICADA DE MODELOS (UML) 2.1Introduo

Antes da UML, havia uma diversidade imensa e improdutiva de abordagens de modelagem, e sua convergncia na UML 1.0 foi um passo frente significante na utilizao de modelos no desenvolvimento de software. Cada desenvolvedor usava a abordagem do autor de sua preferncia, que nem sempre convergiam suas opinies em torno do tema. Outro problema era a proliferao de ferramentas grficas especficas 28

ModelageM de Processos
para uma determinada notao para uma metodologia OO tambm especfica e, na maioria das vezes, proprietrias. Ivar Jacobson, Grady Booch e Jim Rumbaugh, em 1995, tomaram a iniciativa de unificar os mtodos OOSE (Object Oriented Software Engineering), o mtodo Booch93 e o OMT (Object Modeling Technique) e deram o nome de UML. UML significa Unified Modeling Language e uma ferramenta para modelagem de sistemas de todas as complexidades (MEDEIROS, 2004). Lembrete UML significa Unified Modeling Language (Linguagem Unificada de Modelos) e uma ferramenta para modelagem de sistemas de todas as complexidades, (MEDEIROS, 2004). Em 1999, na verso 1.3, a UML passou a ser mantida pela OMG (Object Management Group), que um grupo americano responsvel pela padronizao do uso da orientao a objetos nos Estados Unidos. A UML firma-se ento no mercado e passa a ser um padro internacional para a especificao e modelagem de sistemas aplicativos em todas as reas de abrangncia da rea de informtica ou TI (Tecnologia da Informao). A finalidade da UML proporcionar um padro para a especificao e arquitetura de projetos de sistemas, desde os aspectos conceituais at as solues concretas, tais como, as classes de objetos, esquemas de banco de dados e componentes de software reusveis (BOOCH; RUMBAUGH e JACOBSON, 1999). A UML foi criada para ser independe de processo de software. Os desenvolvedores podem pegar alguma coisa da UML que seja apropriado para seu prprio tipo de projeto e para seu prprio processo, usando a UML para registrar os resultados de suas decises de anlise e design. Lembrete A garantia de ser um padro internacional levou a UML a ser adotada pela OMG que especifica e mantm o metamodelo UML. A especificao da UML, na OMG, definida usando-se uma abordagem de metamodelo, (isto , um metamodelo usado para especificar o modelo que compreende a UML), que adota tcnicas de especificao formal. Por outro lado, enquanto essa abordagem usa o rigor de um mtodo formal de especificao, tambm oferece a vantagem de ser mais intuitivo e pragmtico para a maioria dos implementadores e praticantes. 29

Unidade I
O metamodelo da UML foi projetada com os princpios de design flexvel, tendo em mente o seguinte: Modularidade: o princpio da forte coeso e baixo acoplamento aplicado para a construo em pacotes, que permitem organizar recursos em metaclasses. Camadas: o conceito de camadas aplicado para o metamodelo UML. Particionamento: o particionamento usado para organizar as reas conceituais dentro de uma mesma camada. Extensibilidade: a UML pode ser estendida de duas maneiras: Um novo dialeto da UML pode ser definido por meio de perfis para personalizar o idioma para plataformas especficas (por exemplo, (J2EE/EJB, .NET / COM +) e domnios (por exemplo, finanas, telecomunicaes, aeroespacial). Uma nova linguagem relacionada UML pode ser especificada por reutilizar parte do pacote e bibliotecas de InfraEstrutura dessa. Reutilizao: a biblioteca do metamodelo flexvel para permitir que seja reutilizada para definir o metamodelo UML, bem como outros metamodelos arquitetnicos relacionados, tais como, o Meta Object Facility (MOF) e o Common Warehouse Metamodel (CWM). A infraestrutura da UML definida pela biblioteca de InfraEstrutura UML, pertencente e definida pela OMG. A OMG uma associao internacional, aberta, sem fins lucrativos e um consrcio da indstria de computador desde 1989. Qualquer organizao pode participar da OMG e dos processos de definio das normas. A poltica da OMG garante que todas as organizaes, grandes e pequenas, tenham uma voz eficaz no seu processo. A associao inclui centenas de organizaes, sendo metade de softwares finais e a outra metade representando praticamente todas as organizaes da indstria de computadores. Quando metamodelamos, primeiramente distinguimos entre metamodelos e modelos. Um modelo deve ser instanciado a partir de um metamodelo que, por sua vez, pode ser usado como um metamodelo de outro modelo de forma recursiva. Um modelo normalmente contm os elementos do modelo. Esses so criados instanciando-se os elementos do modelo a partir de um metamodelo. O papel tpico de um metamodelo definir a semntica de como os elementos do modelo em um modelo podem ser instanciados. Como exemplo, considere-se a figura 4, em que as metaclasses Classe e Associao so ambas definidas como parte do metamodelo UML. 30

ModelageM de Processos
Essas so instanciadas em um modelo de usurio ou desenvolvedor, de modo que as classes Pessoa e Carro so as duas instncias da metaclasse Classe, e a associao entre as classes um exemplo da metaclasse Associao. A Figura 8 mostra todos os relacionamentos entre o metamodelo e o modelo do sistema que est sendo desenvolvido.
Metalmodelo UML Classe

Associao

InstnciaDe Modelo do sistema Pessoa Carro

Figura 8 Exemplo de metamodelagem (note que todos os relacionamentos so mostrados no diagrama)

A semntica da UML define o que acontece quando o usurio define os elementos que so instanciados em seu modelo.

Saiba mais Na atualidade, a UML encontra-se na verso 2.3 e composta de 13 diagramas. A especificao formal da UML 2.3 pode ser encontrada no endereo <www.omg.org/spec/UML/2.3/>. Quadro 1 Diagramas da UML
Nmero 1 2 3 4 5 Diagramas 6 7 8 9 10 11 12 13 UML 1.X Atividade UML 2.3 Atividade Caso de uso Classe de objetos Objetos Sequncia Comunicao Estado Componentes Implantao Pacotes Interao Tempo Estrutura composta

Caso de uso
Classe de objetos Objetos Sequncia Colaborao Estado Componentes Implantao --------------------------------------------

31

Unidade I
A proposta da UML no dizer como se deve fazer um software, mas sim proporcionar formas ou maneiras que podem ser utilizadas para representar um software de acordo com a fase do desenvolvimento. Ela prope modelos para a fase de especificao, outros modelos para a fase de design e modelos para o momento de se definir as lgicas dos programas ou transaes. Todas essas formas ou modelos obedecem s regras e fundamentos da orientao a objetos na construo de softwares. Conforme Medeiros (2004), apesar da definio dos trs amigos, pode-se dizer que a UML uma forma de comunicar uma idia, e busca um padro para a cincia da computao com relao comunicao de pessoas da rea, e no uma linguagem de computador. A UML no um processo de desenvolvimento, tais como, o modelo cascade, ou o modelo RUP (Rational Unified Process), ou o processo gil SCRUM. uma linguagem de comunicao que pode ser utilizada em qualquer processo de software dentro de seu ciclo de vida. Hoje, uma linguagem de modelagem bem definida, expressiva, poderosa e geralmente aplicvel a diversos tipos de sistemas, dos mais simples at os mais complexos. Alm disso, a UML no proprietria e aberta a todos. Com a aprovao da UML em novembro de 1997 pela OMG, a guerra de mtodos OO havia chegado ao seu final. De acordo com a UML, ela pode ser usada para: Mostrar as fronteiras de um sistema e suas funes principais. Aqui se introduziu os conceitos de atores e casos de uso. Ilustrar a realizao de casos de uso com diagramas de interaes. Representar uma estrutura esttica de um sistema utilizando diagramas de classes. Modelar o comportamento de objetos com diagramas de transio de estado. Revelar a arquitetura de implementao fsica com diagramas de componentes e de implantao (deployment). Estender sua funcionalidade a partir de esteretipos.
2.2 A UML e o Processo Unificado

Para se falar de um processo de software, necessrio alguns conceitos envolvidos com a Engenharia de software. 32

ModelageM de Processos
2.2.1 Engenharia de software e processos de software Mas o que a Engenharia de software? A Engenharia de software pode ser conceituda como: Uma disciplina de Engenharia voltada para todos os aspectos da produo de software de qualidade. A Engenharia de software estuda processos, modelos e metodologias de desenvolvimento, a gerncia de projeto de software, investigao de novos mtodos, ferramentas e teorias correlatas, tais como, a qualidade e a produtividade. Envolve a escolha seletiva de mtodos e ferramentas adequados para o atendimento de um determinado contexto (restries) de sistema de computao. Abrange todo o ciclo de vida do software, desde a especificao inicial do sistema at sua operao e manuteno. A Engenharia de software est baseada em pilares que lhe do sustentao. A figura 9 mostra um esquema dessa viso da ES.
Engenharia de software(s)

Processos/ guias/prticas/ metodologias

Tcnicas mtodos mtricas

Ferramentas

Qualidade/ produtividade

Gerncia governana

Figura 9 Pilares da Engenharia de software

O estudo dos mtodos/tcnicas/mtricas definem a sequncia, a simbologia e os padres em que as atividades devem ser aplicadas no desenvolvimento e manuteno de software. Com relao s ferramentas, a ES estuda e prope a automatizao dos mtodos e tcnicas. Essas ferramentas de software so chamadas de ferramentas Case (Computer Aided Software Engineering). A qualidade pode ser definida como um conjunto de modelos que apoiam o processo de desenvolvimento na construo de softwares de qualidade. Com as ferramentas, procura-se tambm a melhoria da produtividade das equipes de desenvolvimento. A gesto/gerncia/governana inclui o planejamento de projetos, controle dos projetos, alocao de recursos, cronogramas e indicadores que apoiem na busca da garantia da qualidade dos produtos confeccionados e no alinhamento da rea de TI com as estratgias empresariais. 33

Unidade I
Dentro dessa abrangncia da ES, um dos aspectos mais importantes o estudo dos processos envolvidos com o software.

Saiba mais A Engenharia de Software uma disciplina que adotada nos cursos de Cincia da Computao, Sistemas de Informao e Engenharia da Computao e cobre todo ciclo de vida de um sistema ou software . Os principais livros adotados pelos cursos so: Engenharia de software, de Roger. S. Pressman, editado no Brasil McGraw Hill; o livro Engenharia de software, de Ian Sommerville, editado pela Addison-Wesley; o livro Engenharia de software teoria e prtica, de James F. Peters e Witpd Pedrycz, editado pela Editora Campos; e o Livro Engenharia de software fundamentos, mtdos e padres, de Wilson de Pdua Paula Filho, editado pela LTC. Mas, o que um processo de software? Um processo de software um conjunto estruturado de atividades (ou fases) necessrias para produzir um produto de software. Um processo de software completo abrange as grandes fases de especificao, design ou projeto, a implementao e a manuteno ou evoluo do software. Os processos de software so organizados segundo diferentes modelos de desenvolvimento. Quais so os modelos ou processos de software mais conhecidos? Ao longo do tempo, desde a dcada de 1960, a Engenharia de software desenvolveu diferentes representaes abstratas das fases de um processo de software e suas interdependncias. Os modelos mais representativos e utilizados na Engenharia de software so: Modelo cascata (ou clssico): O paradigma do ciclo de vida clssico ou cascade demanda uma abordagem sistemtica e sequencial para o desenvolvimento de software. Comea em termos de sistema e progride por meio da anlise, design, codificao, teste e manuteno. 34

ModelageM de Processos
A figura 10 mostra um esquema visual do modelo cascade ou cascata.
Engenharia de Sistemas Anlise

Design
Codificao Teste Manuteno

Figrura 10 Ciclo de vida clssico

Todavia, os projetos reais raramente seguem um fluxo sequencial que o modelo prope. Ocorrem interaes, voltas a nveis anteriores, provocando problemas na aplicao do paradigma clssico. Frequentemente, os usurios tm dificuldade de estabelecer explicitamente todos os requisitos do software, acompanhados das incertezas naturais que existem no incio de muitos projetos. Os usurios tem que ser muito pacientes. Uma verso do software somente estar disponvel quando todo o sistema for definido e desenvolvido. Qualquer alterao pode ocasionar um desastre no desenvolvimento do sistema. Esses problemas so reais, porm o paradigma do ciclo clssico de software tem um definitivo e importante lugar na Engenharia de software, pois ele proporciona um modelo real para o uso dos mtodos para analisar, projetar, codificar, testar e manter softwares. Espiral: O modelo espiral para a ES foi desenvolvido para abranger as melhores caractersticas do ciclo clssico, adicionando um novo elemento chamado anlise de risco. O modelo apresenta quatro grandes atividades: Planejamento: determinao dos objetivos, alternativas e requerimentos. Anlise de risco: anlise das alternativas e identificao e resoluo dos riscos. 35

Unidade I
Engenharia: desenvolvimento do prximo nvel do produto. Avaliao do cliente: aceite dos resultados da Engenharia. O modelo espiral desenvolve o software passo a passo. Cada novo ciclo pressupe um maior detalhamento do software, sua construo por meio ou no de prototipagem e um uso real para aceite dos usurios. A cada final de ciclo e incio de outro, os riscos so avaliados e o projeto pode ser ou no cancelado. O nmero de ciclos no pode ser alto, pois poderia colocar em risco o modelo. O ciclo final utilizado para incorporar a parte de segurana, perfomance e garantias de qualidade ao software. O modelo espiral segue os conceitos da iteratividade ao longo do desenvolvimento de um aplicativo ou projeto de software. Observao Todos os modernos processos de software, inclusive os mtodos geis, consideram a iteratividade e a liberao parcial de um projeto em suas propostas metodolicas, conceitos oriundos do modelo espiral. 4GL tcnicas de quarta gerao: O termo tcnicas de quarta gerao (4GL) abrange um conjunto de ferramentas de software que possuem alguma coisa em comum. Permitem ao desenvolvedor especificar algumas caractersticas do software em alto nvel de abstrao e ento geram automaticamente cdigos fontes baseados nas definies. Os principais ambientes que suportam o paradigma 4GL so: linguagens no procedurais para pesquisas em banco de dados, geradores de relatrios, manipuladores de dados, definidores de telas interativas, geradores de cdigo, geradores de grficos, arquitetura MDA etc. Idntico aos outros paradigmas, o 4GL comea com a especificao dos requisitos junto aos usurios, que devero ser transportados para um prototipador. Os cdigos gerados devero ser testados e aprovados para que o sistema possa ser considerado pronto. As tcnicas de quarta gerao tm se tornado uma parte importante da ES, principalmente na rea de sistemas de informao gerenciais. O que se ve uma diminuio cada vez maior no uso de mtodos tradicionais no desenvolvimento de sistemas, e o crescimento no uso das tcnicas de quarta gerao. 36

ModelageM de Processos
2.2.2 Os processos denominados de geis Os processos geis ou a modelagem gil um processo baseado nas prticas que descrevem como um modelador gil deve agir. A motivao devido s estratgias atuais ou clssicas de modelagem que, muitas vezes, no se mostram funcionais ou so consideradas muito pesadas e burocrticas. Em um extremo, a modelagem no existe; do outro, se produz modelagem em excesso. De acordo com Scott W. Ambler, a modelagem gil se prope a encontrar um meio termo, o qual permita uma modelagem suficiente para explorar e documentar um sistema de modo eficaz, mas no a ponto de tornar isso um fardo e fatalmente torn-lo um fracasso. As tcnicas da modelagem gil podem e devem ser aplicadas por equipes de projetos que desejam empregar uma estratgia gil de desenvolvimento de software. Os principais frameworks ou modelos ou mtodos geis da atualidade so: XP (Xtremme Programming), SCRUM, Crystal, AUP (gile Unified Process), ICONIX etc.

Saiba mais Roger S. Pressman, em seu livro Engenharia de software (6 ed., 2006), nas pginas 59 a 76, faz uma abordagem sinttica sobre os mtodos geis que ele denomina de desenvolvimento gil, que se inicia com a discusso do que agilidade, passa pelos conceitos de um processo gil e apresenta os principais modelos ou mtodos geis em uso no mbito internacional, tais como: a Extreme Programming (XP), o Scrum, o Crystal, o FDD (Desenvolvimento Guiado por Caractersticas) e a Modelagem gil. 2.2.3 O Processo Unificado UP O processo unificado UP (Unified Process) um processo de software composto por quatro fases: a fase de concepo, de elaborao, de construo e de transio. O processo unificado, que depois foi extendido para o processo RUP (Rational Unified Process), todo baseado na UML cujos diagramas e modelos cobrem praticamente todo o ciclo de desenvolvimento desses modelos. A figura 11 mostra um diagrama criado por Scott W. Ambler que mostra, na vertical, as fases da UP e, na horizontal, as disciplinas aplicadas nas fases. 37

Unidade I
Phases Inception Model Implementation Test Deployment Configuration management Project management Environment I1 E1 C1 C2 Cn T1 T2 Elaboration Construction Transition

Figura 11 A UP vista sob a tica dos modelos geis proposta por Scott W. Ambler

A fase inception seria a fase de concepo, a fase Elaboration seria a fase de elaborao, a fase Construction a fase de construo e a fase Transition a fase de transio. Na fase de concepo, se definem os requisitos do software e se avalia a tecnologia necessria para uma soluo aderente s necessidades do cliente. Nesse ponto, tambm importante que sejam considerados os riscos principais envolvidos com o software a ser desenvolvido. Diversos diagramas e modelos da UML (disciplina Model) podem ser utilizados nessa fase, sendo o mais importante modelo de casos de uso em um nvel mais abstrato, j que no se pode demorar muito para se fazer uma proposta comercial e tcnica ao cliente envolvido. Na fase de elaborao, na qual para a UP se detalham os requisitos, a UML apia com diversos diagramas e modelos (disciplina Model), tais como: o modelo de casos de uso com os cenrios detalhados, diagrama de atividades (para especificaes visuais de lgicas mais complexas), diagramas de estado, diagrama de classes em nvel de domnio e outros que se fizerem necessrios para deixar as especificaes suficientes para a implementao. A fase de construo quando se pensa em prottipos, em banco de dados e lgicas de programao. A UML, nessa fase, contribui com os diagramas de sequncia, comunicao, tempo, pacotes, implantao e componentes. Se o processo iterativo e incremental, no qual o software no liberado todo de uma nica vez, mas desenvolvido e liberado em pedaos, a fase de construo consiste de muitas iteraes, em que constri-se software, testa-se e faz-se a integrao que satisfaa um conjunto de requisitos do projeto. J na fase de transio, estamos falando dos testes e homologao, dos quais a UML no possui diagramas ou modelos de suporte diretamente. 38

ModelageM de Processos

Resumo Este captulo apresentou um histrico e conceitos da modelagem de software e o histrico da linguagem de modelos UML. Modelar sistemas a capacidade de simplificar a complexidade inerente aos sistemas de informao. A construo de modelos permite se enxergar o todo antes de se iniciar a construo ou programao propriamente dita. Modelar significa desenhar e pensar antes de fazer. Permite a passagem de conhecimento para outras pessoas que saibam ler os desenhos e as plantas do sistema. Significa, no final, que os sistemas fiquem menos dependentes de pessoas e passem a ser uma propriedade coletiva. Bom para os profissionais e bom para as empresas de software. importante salientar que a UML uma linguagem de modelagem, no uma metodologia de desenvolvimento de software. A UML define uma notao e um metamodelo. A notao o material grfico visto em modelos, a sintaxe da linguagem de modelagem. Ainda sobre a tecnologia orientada a objetos: As tcnicas baseadas em objetos simplificam o projeto de sistemas complexos. A tecnologia de objetos visualiza os sistemas como uma coleo de objetos, cada um deles em um determinado estado, dentre muitos estados existentes. A revoluo na indstria de software indica um movimento em direo a uma era em que os softwares sero montados a partir de componentes reutilizveis. Os componentes sero criados a partir de componentes existentes, e sero criadas grandes bibliotecas desses componentes. 39

Unidade I
Novamente, discute-se com bastante veemncia o conceito das caixas-pretas, cujo interior no enxergamos, apesar de sabermos o que elas fazem ou produzem. As tcnicas baseadas em objetos sozinhas no podem prover a magnitude da mudana necessria. Elas tm de ser combinadas com outras tecnologias. As tecnologias ditas otimizadoras so: ferramentas Case; programao visual; geradores de cdigo; repositrio central de dados e mdulos/componentes; metodologias baseadas em objetos; banco de dados orientado a objetos; linguagens no procedurais; mtodos formais baseados na matemtica; tecnologia cliente-servidor, aplicativos orientados a servios (SOA); bibliotecas de classes que maximizem a reusabilidade; abstrao de modelos mais prximas do mundo real. Exerccios Questo 1. Os autores que trabalham os conceitos envolvidos com os objetivos da Engenharia de software afirmam que ela a aplicao de teoria, modelos, formalismos, tcnicas e ferramentas da cincia da computao e reas afins para o desenvolvimento sistemtico de software . Ainda de acordo com os autores, o desenvolvimento de software que utiliza modelos para representar a realidade se torna mais produtivo e gil; aqueles construdos em padres e simbologias predefinidos permitem que os participantes de um projeto, tanto os analistas como os arquitetos e programadores de software , tenham um mesmo entendimento do problema que est sendo resolvido. Os mtodos, as tcnicas e as ferramentas tambm 40

ModelageM de Processos
apoiam o gerenciamento do processo de desenvolvimento, devido principalmente a criao de uma documentao formal, que destinada comunicao entre os membros da equipe e aos usurios do sistema. Considerando os conceitos sobre o uso de modelos no desenvolvimento de software, analise as afirmaes a seguir e assinale a alternativa incorreta: A) O uso de modelos mentais influencia a forma de encararmos o mundo, e o trabalho com modelos permite a realizao de conversas ricas em aprendizados. B) Como os modelos possuem uma sintaxe precisa, geralmente so melhor utilizados com o apoio de uma ferramenta grfica, que, por conter semnticas que determinam como os conceitos especficos de domnio so aplicados, diminuem consideravelmente os erros cometidos no processo de desenvolvimento. C) Como os modelos aplicados na Engenharia de software podem abstrair e agregar informaes de uma srie de artefatos, eles podem ser utilizados para as verificaes de consistncia e para a garantia da qualidade. D) Um modelo pode ser considerado um meio de comunicao entre as pessoas envolvidas em um projeto. Tambm ajuda outros indivduos, que podem utiliz-lo como base para a sua implementao ou para a concepo de novos modelos. E) Os modelos, no processo de desenvolvimento de software, somente possuem caractersticas de comunicao e no conseguem apoiar a equipe na melhoria contnua de seus processos. Resposta: Alternativa E. A modelagem de sistemas de informao ou sistemas de software uma atividade que, a partir da construo de modelos, consegue explicar as caractersticas ou o comportamento de um aplicativo ou de um sistema de software. No processo de desenvolvimento e construo de um software, os modelos podem ser usados na identificao das caractersticas e funcionalidades que o software dever prover e no planejamento de sua construo. Anlise das alternativas A) Correta. Quando se defronta com um problema, o homem desenvolve mentalmente uma srie de abstraes, as quais permitem o encaminhamento de solues. Essas abstraes da realidade so denominadas modelos. B) Correta. Os modelos so acompanhados de padres no seu uso e possuem uma semntica bem definida. As ferramentas denominadas CASE incluem esses padres, conseguindo, assim, orientar e diminuir os possveis erros que possam ser cometidos pelas pessoas. 41

Unidade I
C) Correta. A qualidade de software pressupe que os artefatos produzidos no ciclo de desenvolvimento devem ser verificados passo a passo, para que se tenha uma consistncia nos produtos realizados. Como os modelos representam graficamente os produtos de software, possibilitam revises mais cosistentes pelos participantes de seu processo de construo. D) Correta. Como um modelo representa uma abstrao de uma realidade, outros podem ser construdos para uma soluo de novos aspectos envolvidos com aquela realidade. Um modelo tambm pode ser detalhado com o uso de novos modelos mais especficos dentro da realidade observada. E) Incorreta. Os modelos no processo de desenvolvimento so utilizados por todos os envolvidos no sistema e so considerados como uma forma de entendimento e apoio s atividades do processo de desenvolvimento, que, a partir da avaliao dos problemas encontrados, pode proporcionar a melhoria do processo. Questo 2. A Orientao a Objetos considerada um paradigma para o desenvolvimento de software. Baseia-se na utilizao de componentes individuais (chamados de objetos), que colaboram para construir sistemas mais complexos. Toda a comunicao ou colaborao entre os objetos feita por meio do envio de mensagens (um objeto aciona outro objeto para a execuo de uma operao e aguarda uma resposta). Um paradigma um conjunto de regras que estabelece fronteiras e descreve como resolver problemas dentro dessa fronteira. Um paradigma ajuda o homem a organizar a e coordenar a maneira como ele observa o mundo. Considerando-se os conceitos sobre a Orientao a Objetos, analise as afirmaes a seguir e assinale a alternativa incorreta: A) Dentro da tecnologia OO, um objeto alguma coisa que faz sentido no contexto de uma aplicao e representa uma entidade relevante para o entendimento e para a soluo de uma necessidade de uma atividade ou ao usurio do sistema. B) Como na OO os objetos se comunicam por meio de mensagens, uma mensagem enviada por um objeto causa a ativao de uma operao (mtodo) no objeto alvo para responder ao chamado do objeto ativador ou chamador. C) Na OO, o conceito de polimorfismo surge quando uma operao de um determinado objeto atua de acordo com as definies especficas de sua funcionalidade. D) Para ser utilizada, uma classe de objeto precisa de um mtodo denominado Construtor, que inicializa o objeto quando ele instanciado e disponibiliza os recursos para que sejam utilizados pelos mtodos ou operaes do objeto. E) A UML (Unified Modeling Language) foi desenvolvida na dcada de 1990 para unificar as diversas correntes existentes no desenvolvimento de software que utilizavam a tecnologia da Orientao a Objetos. Resoluo desta questo na Plataforma. 42