modelagem de processos unidade i

Autor: Prof. Dr. Ivanir Costa Colaboradores: Prof. Roberto Macias

Profa. Elisângela Mônaco de MoraesProf. Emanuel Augusto Severino de Matos

Modelagem de Processos

Professor conteudista: Dr. Ivanir Costa

Doutor em Engenharia de Produção pela Escola Politécnica da Universidade de São Paulo (USP, 2003) e mestre em Engenharia de Produção pela Universidade Paulista (UNIP), pós-graduado em Sistemas de Informação pela UNIP, graduado em Física pela USP. Professor titular do programa de mestrado e doutorado da UNIP em Engenharia de Produção, onde realiza orientação para alunos doutorandos, mestrandos e da iniciação científica na graduação. Professor da EAD na UNIP, nas disciplinas de Qualidade de Software e Sistemas de Informação. Orientador de alunos de mestrado do IPT (Instituto de Pesquisas Tecnológicas) da USP, professor do curso Gestão da Tecnologia da Informação, MBA da FIA/FEA. Possui dezenas de publicações na área de Engenharia de Produção e Tecnologia da Informação no Brasil e no exterior. É consultor há mais de 30 anos em Tecnologia da Informação, com ênfase em Engenharia de Software e Qualidade de Software, atuando principalmente nos seguintes temas: desenvolvimento de software, metodologia de desenvolvimento, métricas de software, métodos ágeis, produção de software, qualidade de software e governança de TI.

© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem permissão escrita da Universidade Paulista.

Dados Internacionais de Catalogação na Publicação (CIP)

C837m Costa, Ivanir

Modelagem de processos / Ivanir Costa. – São Paulo: Editora Sol, 2012.

144 p., il.

Notas: este volume está publicado nos Cadernos de Estudos e Pesquisas da UNIP, Série Didática, ano XVII, n. 2-066/12, ISSN 1517-9230.

1. Tecnologia da informação. 2. Modelagem de processos. 3. Modelagem comportamental. I. Título.

CDU 65.011.56

Prof. Dr. João Carlos Di GenioReitor

Prof. Fábio Romeu de CarvalhoVice-Reitor de Planejamento, Administração e Finanças

Profa. Melânia Dalla TorreVice-Reitora de Unidades Universitárias

Prof. Dr. Yugo OkidaVice-Reitor de Pós-Graduação e Pesquisa

Profa. Dra. Marília Ancona-LopezVice-Reitora de Graduação

Unip Interativa – EaD

Profa. Elisabete Brihy

Prof. Marcelo Souza

Profa. Melissa Larrabure

Material Didático – EaD

Comissão editorial: Dra. Angélica L. Carlini (UNIP) Dr. Cid Santos Gesteira (UFBA) Dra. Divane Alves da Silva (UNIP) Dr. Ivan Dias da Motta (CESUMAR) Dra. Kátia Mosorov Alonso (UFMT) Dra. Valéria de Carvalho (UNIP)

Apoio: Profa. Cláudia Regina Baptista – EaD Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos

Projeto gráfico: Prof. Alexandre Ponzetto

Revisão: Virgínia Bilatto Amanda Casale

SumárioModelagem de Processos

APRESENTAÇÃO ......................................................................................................................................................7INTRODUÇÃO ...........................................................................................................................................................7

Unidade I1 A LINGUAGEM UNIFICADA DE MODELOS ..............................................................................................11

1.1 Introdução ................................................................................................................................................111.2 Motivação para o uso de modelos ................................................................................................ 121.3 Princípios da modelagem de software ........................................................................................ 141.4 Modelagem e orientação a objetos .............................................................................................. 151.5 Por que usar a orientação a objetos? ........................................................................................... 161.6 Conceitos básicos da orientação a objetos ................................................................................ 22

2 A LINGUAGEM UNIFICADA DE MODELOS (UML) ................................................................................ 282.1Introdução ................................................................................................................................................ 282.2 A UML e o Processo Unificado ........................................................................................................ 32

2.2.1 Engenharia de software e processos de software ..................................................................... 332.2.2 Os processos denominados de ágeis ............................................................................................... 372.2.3 O Processo Unificado – UP ................................................................................................................. 37

Unidade II3 MODELO CONCEITUAL DA UML ................................................................................................................. 43

3.1 Introdução ............................................................................................................................................... 433.2 Visão geral da UML .............................................................................................................................. 433.3 Arquitetura da UML ............................................................................................................................. 443.4 Modelagem estrutural ........................................................................................................................ 45

3.4.1 Classes de objetos ................................................................................................................................... 453.4.2 Relacionamentos entre classes de objetos/instâncias ............................................................. 463.4.3 Mecanismos comuns ............................................................................................................................. 463.4.4 Diagramas da UML ................................................................................................................................. 47

4 DIAGRAMA DE CLASSES DE OBJETOS DA UML ................................................................................... 514.1 Introdução ............................................................................................................................................... 514.2 Associação ............................................................................................................................................... 534.3 Papéis em associação .......................................................................................................................... 554.4 Classe de associação ........................................................................................................................... 564.5 Agregação e composição .................................................................................................................. 584.6 Generalização/especialização .......................................................................................................... 594.7 Herança .................................................................................................................................................... 604.8 Conceitos avançados envolvendo classes .................................................................................. 63

4.8.1 Herança múltipla .................................................................................................................................... 634.8.2 Classes abstratas ..................................................................................................................................... 65

4.8.3 Polimorfismo (ocultamento de informações) ............................................................................. 664.8.4 Interfaces tipos e papéis ...................................................................................................................... 674.8.5 Pacotes lógicos ........................................................................................................................................ 674.8.6 Objetivos do diagrama de classes .................................................................................................... 68

4.9 Estudo de caso aplicando modelo de classes ........................................................................... 684.9.1 Descrição do sistema ............................................................................................................................. 684.9.2 Requisitos do sistema ........................................................................................................................... 694.9.3 Modelo de classe do sistema ............................................................................................................. 70

Unidade III5 MODELAGEM COMPORTAMENTAL (MODELO DINÂMICO) ............................................................. 76

5.1 Introdução ............................................................................................................................................... 765.2 Modelo de casos de uso .................................................................................................................... 77

5.2.1 Diagramas de caso de uso ................................................................................................................... 776 OUTROS MODELOS COMPORTAMENTAIS DA UML ............................................................................ 91

6.1 Introdução ............................................................................................................................................... 916.2 Diagrama de atividades ..................................................................................................................... 926.3 Diagrama de sequência ...................................................................................................................... 93

6.3.1 Linha de vida............................................................................................................................................. 956.3.2 Ativação ...................................................................................................................................................... 956.3.3 Autodelegação ......................................................................................................................................... 956.3.4 Mensagem ................................................................................................................................................. 95

6.4 Diagramas de estado (máquina de estado) ............................................................................... 966.4.1 Estado .......................................................................................................................................................... 966.4.2 Notações ..................................................................................................................................................... 966.4.3 Evento .......................................................................................................................................................... 976.4.4 Transição ..................................................................................................................................................... 98

Unidade IV

7 MODELAGEM DA ARQUITETURA DE NEGÓCIO .................................................................................1037.1 Introdução .............................................................................................................................................1037.2 Modelagem de negócio ...................................................................................................................104

7.2.1 Conceitos de negócio ..........................................................................................................................1057.2.2 Extensão de negócio da UML ........................................................................................................... 1107.2.3 Visões de modelos de negócio ........................................................................................................114

7.3 OCL e sua utilização na modelagem de processo de negócio ......................................... 1147.4 Integração com o desenvolvimento de software .................................................................. 116

7.4.1 Processo de desenvolvimento de software ................................................................................1167.4.2 Arquitetura de negócio e arquitetura de software .................................................................117

8 A MODELAGEM DE PROCESSOS DE NEGÓCIO .................................................................................. 1198.1 Visão Erikson e Penker ...................................................................................................................... 1198.2 A modelagem de processos de negócio com a BPM ...........................................................122

8.2.1 Objetos de fluxo ................................................................................................................................... 1258.2.2 Objetos de conexão ............................................................................................................................. 1278.2.3 Raias (Swimlanes) ................................................................................................................................ 1298.2.4 Artefatos ...................................................................................................................................................131

8.3 Conclusão do BPMN .........................................................................................................................133

7

APRESENTAÇÃO

O objetivo da disciplina Modelagem de Processos é apresentar e conceituar a importância de modelos no desenvolvimento de sistemas de informação.

Nela, os alunos terão condições 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 estáticos como os modelos dinâmicos.

A disciplina também apresenta os conceitos e simbologias envolvidos com a modelagem das áreas de negócio, bem como os mapeamentos de negócios por meio da UML e da moderna linguagem de modelagem de negócios BPMN (Business Process Modeling Notation).

INTRODUÇÃO

Entre os autores e especialistas envolvidos com os processos de desenvolvimento de software, existe a crença de que, de algum modo, a modelagem pode ser aplicada para facilitar a nossa vida.

Desde a década de 1970, os autores especializados em software vêm 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 importância desse entendimento torna-se primordial, já que no processo de software temos a participação de pessoas de diversas áreas de uma organização, indo do usuário final de uma área de negócio até o especialista em software e hardware da área de TI.

Todavia, ao longo desse tempo, a modelagem de software vem sendo criticada devido à percepção de que a modelagem é uma atividade que precede o desenvolvimento real e que tem como foco a documentação. Isto é, para muitos especialistas, não se deve privilegiar o desenho ao próprio desenvolvimento. Essas críticas vieram principalmente dos defensores dos métodos ágeis, que privilegiam o código em vez da documentação.

Outros autores, entretanto, insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento central importante. Quando os modelos são considerados parte das atividades do processo de desenvolvimento e geram artefatos de primeira classe, os desenvolvedores geram menos código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser empregadas.

Dessa forma, quando os modelos abrangem as atividades de desenvolvimento, a comunicação entre as pessoas envolvidas pode ser otimizada e a capacidade de rastreamento ativada no ciclo de vida em qualquer direção. A otimização também vem do fato de que os modelos podem ser fontes de reuso tanto dos objetos criados como das descrições que os envolvem.

Acredita-se que tornar a modelagem uma corrente predominante dentro da área de desenvolvimento de sistemas de uma organização pode levar a uma economia de recursos e, com isso, aumentar a

8

abrangência de automação no atendimento das necessidades de uma empresa. A automação do processo de desenvolvimento com o uso de geradores de sistemas a partir de modelos construídos tende a ser uma realidade a médio e longo prazos no processo de software.

Pode-se citar, dentro dessa realidade, a Microsoft, que emitiu um documento denominado de “Estratégia de modelagem” em 2005, que aborda o desenvolvimento dirigido por modelo dentro de uma iniciativa chamada Fábricas de Software.

Existem diversas empresas, órgãos e grupos que adotam e propõem 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 adoção ocorreu em um evento histórico e marcante, pois assinalou a aceitação de uma linguagem padronizada de modelagem de sistemas baseada nas melhores práticas atuais para a análise, o projeto e a construção de software orientado a objetos.

A UML, tema central desta disciplina, é a primeira notação que atingiu o consenso entre a maioria dos profissionais, vendedores e acadêmicos como o padrão real para expressar um domínio comercial da solução 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 construção do sistema.

4. Documentar as decisões tomadas pela equipe de desenvolvimento de projeto.

A UML precisa desses objetivos para ser efetiva (REED Jr., 2000).

Ela é apresentada tanto nos seus modelos estáticos como nos modelos dinâmicos que mostram as estruturas e os comportamentos dos objetos envolvidos em uma determinada aplicação ou software nos modelos da tecnologia orientada a objetos.

Na atualidade, outra área de interesse e importante na construção de sistemas fundamentais é a de processos de negócio, que se propõe a mostrar as atividades previamente estabelecidas nas áreas de negócio e determinar a forma como o trabalho é realizado numa organização.

Essas atividades de negócio constituem um conjunto de ações relacionadas entre si de forma lógica e coerente, a fim de promover uma saída favorável à organização, em níveis interno e externo. Uma boa modelagem dos processos de negócio leva à implementação de um sistema de informação bem-estruturado.

9

A disciplina aborda os conceitos de modelos, a importância da modelagem de sistemas de informação, a tecnologia orientada a objetos e as modelagens UML e BPM no processo de desenvolvimento de software.

11

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

ModelageM de Processos

Unidade I1 A LINgUAgEM UNIfICADA DE MODELOS

1.1 Introdução

Existe uma crença, 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 à percepção de que é uma atividade que precede o desenvolvimento real e que tem como foco a documentação.

Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento central importante e não uma atividade focada principalmente em documentação.

Quando os modelos são considerados artefatos de desenvolvimento de primeira classe, os desenvolvedores geram menos código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser empregadas.

Assim, o desenvolvimento dirigido por modelo é inerentemente mais produtivo e ágil. Além disso, outros participantes no desenvolvimento como analistas de negócios, arquitetos e gerentes de projetos, irão reconhecer a modelagem como o que adiciona valor às tarefas pelas quais são responsáveis.

Quando os modelos abrangem as atividades de desenvolvimento e em tempo de execução dessa maneira, a comunicação entre as pessoas pode ser otimizada, e a capacidade de rastreamento ativada no ciclo de vida em qualquer direção.

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 Estratégia de modelagem, de 2005, essa abordagem do desenvolvimento dirigido por modelo é parte de uma iniciativa chamada Fábricas de software.

12

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Saiba mais

Vale a pena ler o artigo de maio de 2005, disponível no site <http://msdn.microsoft.com/pt-br/library/ms379623(v=vs.80).aspx>, que discute a estratégia de desenvolvimento da Microsoft, dirigido por modelos com uma série de perguntas e respostas relativas a esses tópicos e interesses. Esse artigo basicamente pergunta e responde: por que modelagem? Como as DSLs são usadas no desenvolvimento dirigido por modelo? E quanto à UML? E quanto à MDA? O que são fábricas de software?

1.2 Motivação para o uso de modelos

Ainda de acordo com a Microsoft, um modelo deve ser um artefato de primeira classe em um projeto, não apenas uma documentação aguardando para se tornar desatualizada.

O autor Senge (1990):

1. Define que modelos são mentais, são pressuspostos profundamente arraigados, generalizações, ou mesmo imagens que influenciam a forma de ver o mundo e de nele agir. Muitas vezes, não estamos conscientes de nossos modelos mentais ou de seus efeitos sobre nosso comportamento.

2. Afirma que o trabalho com modelos mentais inclui também a capacidade de realizar conversas ricas em aprendizados, que equilibrem indagação e argumentação, em que as pessoas exponham de forma eficaz seus próprios pensamentos e estejam abertas à influência dos outros.

3. Os modelos possuem uma sintaxe precisa, geralmente são melhores editados e visualizados com uma ferramenta gráfica e contêm semânticas que determinam como conceitos específicos de domínio mapeiam para outros artefatos de implementação, como: código, estruturas de projeto e arquivos de configuração.

4. Dessa maneira, um modelo se parece muito com um arquivo de código-fonte, e os mecanismos que o sincronizam com outros artefatos de implementação são muito semelhantes a compiladores.

5. Um modelo representa um conjunto de abstrações que dá suporte a um desenvolvedor em um aspecto de desenvolvimento bem definido.

6. Como os modelos podem abstrair e agregar informações de uma série de artefatos, podem dar suporte de modo mais rápido a verificações de consistência e outras formas de análise.

13

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Observação

Um modelo de conectividade de aplicativos, por exemplo, poderá suportar validação de protocolo de contrato, análise de segurança ou análise de desempenho.

Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema segundo uma estrutura de conceitos.

Um modelo apresenta “apenas” uma visão ou cenário de um fragmento do todo. Normalmente, para estudar um determinado fenômeno complexo, criam-se vários modelos.

Observação

Por exemplo, pode-se citar obras da Engenharia civil, tais como, uma grande obra hidráulica, uma ampliação de uma praia artificial ou mesmo uma usina hidrelétrica, não são projetadas sem estudos detalhados em vários tipos de modelos matemáticos de diversas categorias e tipos, como modelos de hidrologia, hidráulica e mecânica dos solos.

Modelagem também pode ser vista como a arte de criar moldes tanto em fundição (nesse caso, os de areia), como em calçados e em confecção de peças para o vestuário. No caso dessa última, o molde é obtido por uma das três técnicas básicas: moulage, modelagem geométrica ou simples cópia.

Segundo os autores Huckvale e Ould (1993, apud BRANCO, 2007), um modelo aplicado a processos oferece:

• Um meio para discussão: o modelo de processos ajuda a situar as questões relevantes ao permitir a abstração do mundo real, salientando os objetos e relacionamentos que são de interesse e ignorando detalhes que possam contribuir para aumentar a complexidade.

• Um meio para comunicação: permite que outras pessoas, que não as envolvidas no desenvolvimento do modelo, possam utilizá-lo como base para a sua implementação ou para a concepção de novos modelos.

• Uma base para análise: a análise de um modelo pode revelar os pontos fortes e fracos do processo, com especial relevância para os fracos, como ações que acrescentam pouco valor ou são potenciais focos de problemas.

• A análise por simulação e animação do modelo permite, ainda, estudar os efeitos que possíveis alterações podem causar em um dado processo.

14

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

• Uma base para concepção de novos processos.

• Uma base para melhoria contínua: as sugestões para a mudança podem ser expressas em termos de alterações ao modelo e da sua análise, sendo possível ainda sugerir métricas para avaliar o seu desempenho.

• Uma base para controle: quando suficientemente formal para ser automatizado, o modelo pode ser utilizado para controlar a execução do sistema modelado, como em um sistema de gestão de Workflow.

• Além de garantir o correto funcionamento, permite efetuar medições quanto ao desempenho do processo.

1.3 Princípios da modelagem de software

A modelagem de sistemas de informação (software) é a atividade de construir modelos que expliquem as características ou o comportamento de um software ou aplicativo, ou de um sistema de software.

Na construção do software, os modelos podem ser usados na identificação das características e funcionalidades que o esse deverá prover e no planejamento de sua construção.

Frequentemente, a modelagem de software usa algum tipo de notação gráfica e é apoiada pelo uso de ferramentas de apoio denominadas de ferramentas Case.

Ferramentas Case (Computer-Aided Software Engineering) é uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de software, desde análise de requisitos e modelagem até programação e testes.

Podem ser consideradas como ferramentas automatizadas que têm como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.

A modelagem de software normalmente implica a construção de modelos gráficos que simbolizam os artefatos dos componentes de software utilizados e os seus inter-relacionamentos.

Uma forma comum de modelagem de programas procedurais (não orientados a objeto) é por meio de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usa a linguagem gráfica de modelos UML.

Observação

Vale a pena, para quem ainda não 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

15

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


uma série de propriedades e facilidades que ajudam na documentação, facilitam a comunicação e ainda aumentam de forma considerável a produtividade dos desenvolvedores de software. Algumas são tão sofisticadas que chegam a gerar código diretamente dos modelos construídos.

1.4 Modelagem e orientação a objetos

De acordo com vários autores, há muito tempo busca-se um padrão de construção de software orientado a objetos e sua representação, à semelhança da planta utilizada por outras áreas da Engenharia, tal como a planta de uma casa ou arquitetura de um prédio da Engenharia Civil.

O enfoque tradicional de modelagem para a construção de sistemas de informação baseia-se na compreensão 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 coletânea de objetos que interagem entre si e apresentam características próprias, que são representadas pelos seus atributos (dados) e operações (processos) (FURLAN, 1998).

A figura 1 mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.

Programa Classe

Atributos

Operações

Foco em sistema Foco em objeto

Processos

Dados

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. Então, o programa é representado por classes; os processos, por operações ou métodos; e os dados, por atributos dos objetos.

Essa mudança 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.

16

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Carros, equipamentos, pessoas, bancos etc. apresentam características próprias que podem ser representadas pelos seus atributos e pelos seus comportamentos no mundo real.

Furlan (1998) informa que essa abordagem oferece como principais benefícios:

• manter a modelagem do sistema e, em decorrência, sua automação o mais próximo possível de uma visão conceitual do mundo real;

• servir de base à decomposição e modelagem do sistema nos dados, que é o elemento mais estável de todos aqueles que compõem um sistema de informação;

• oferecer maior tranparência na passagem de modelagem para a construção por meio da introdução de detalhes, não requerendo uma reorganização do modelo.

Lembrete

Embora o termo “orientação a objetos” tenha sido usado de várias formas distintas, deveria sempre sugerir uma associação 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, assíncrona e concorrente.

Diz-se que um objeto “sabe coisas”, isto é, armazena dados; objeto “realiza trabalho”, isto é, encapsula serviços; objeto “colabora” com outros objetos por meio de troca de mensagens, para executar as funções finais do sistema, sendo modelado.

James Rumbaugh (1994) define orientação 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 orientação a objetos?

Dentre as várias razões pode-se citar:

• Inconsistência na visão dos modelos:

— Diferentemente das outras tecnologias de desenvolvimento, o mesmo conjunto de modelos na OO é utilizado em todo o ciclo de desenvolvimento.

17

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


— Os objetos são:

– Descobertos na fase de análise de sistemas para representar os requisitos do usuário.

– Alterado na fase de projeto para incorporar as características do ambiente operacional do sistema.

– E finalmente utilizado na fase de construção para subsidiar a implementação nas linguagens OO e nos gerenciadores de banco de dados.

— Objetos definidos na análise têm representação direta no código, evidenciando a relação entre a definição do problema e a sua implementação.

• Melhor abstração do domínio do problema:

— A OO mantém uma forte coesão 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 método que possibilitasse o reuso de código, prometida por todos, mas nunca alcançado.

— A OO, com a implementação do conceito de generalização e especialização, a partir da herança, possibilitam isto.

• Melhor suporte à integridade:

— Interação entre os componentes OO é restrita a poucas interfaces que são bem definidas.

— A única forma de comunicação entre os objetos se dá por meio de troca de mensagens.

• Suporte decorrencial à concorrência:

— A sincronização de suas partes pode ser mostrada por meio de diagramas e da passagem de mensagens entre os objetos do sistema.

• Uso de herança:

— Identifica e aproveita os pontos comuns dos dados e serviços (operações, rotinas, métodos). Herança é sinônimo de reusabilidade.

A orientação 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.

18

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Afirma-se que, dessa forma, uma aplicação (sistema) no universo de objetos consiste de um conjunto de blocos de construção autocontidos e predefinidos que podem ser localizados, reparados ou substituídos.

Lembrete

Uma das coisas mais importantes da modelagem orientada a objetos está na reusabilidade. As técnicas de orientação a objetos permitem reutilizar muito mais do que o código. Com os modelos orientados a objetos, pode-se reutilizar requisitos, análise, projeto, planejamento de testes, interfaces de usuários e arquiteturas.

Praticamente todos os componentes do ciclo de vida da Engenharia de software podem ser encapsulados como objetos reusáveis (YOURDON, 1998).

A essência da análise e do desenho orientados a objetos de uma aplicação de software é a descrição de comportamentos. Modelos dinâmicos são utilizados para implementar os comportamentos que atendem às necessidades e metas do usuário.

As disciplinas de análise e de desenho com objetos apresentam técnicas utilizadas para separar e encapsular os comportamentos das aplicações de software.

Os diferentes modelos elaborados durante a análise e o desenho são utilizados de acordo com a sua natureza:

• Modelo dinâmico: descreve os comportamentos exibidos pelo computador, quando esse realiza os serviços solicitados pelo usuário.

• Modelo estático: descreve a estrutura lógica do computador, de modo que ele se comporte de maneira adequada, e gerencia as dependências entre as diversas partes lógicas do computador.

A modelagem orientada a objetos inicia-se com a análise orientada a objetos (AOO), que estabelece o comportamento fundamental de um sistema, comportamento que pode ser mantido independentemente de como o sistema será construído.

Na análise OO, são construídos modelos formais de um sistema de software proposto (semelhante aos modelos em escala de um prédio feitos por um arquiteto ou engenheiro civil), que capturam os requisitos essenciais do sistema.

Esse modelo deve ser documentado em uma notação ou linguagem simbólica, de preferência conhecida e testada no mercado de software.

Um modelo de AOO retrata objetos que representam um domínio de aplicação específico, juntamente com diversos relacionamentos estruturais e de comunicação.

19

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


De acordo com Yourdon (1998), o modelo de AOO serve para dois propósitos: primeiro, para formalizar a visão do mundo real dentro do qual o sistema de software será construído; 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 visões, conforme a figura 2, que permitem visualizá-lo de perspectivas distintas.

Nome da camada Símbolos

Classes e objetosBordas da classe

Borda da instância (objeto)

Atributos

Atributos

Conexão entre objetos

ServiçosMensagens

Serviços

Estruturas

Assuntos Assuntos

Figura 2 – Estrutura de um modelo de AOO

A camada de classes e objetos apresenta os blocos básicos de construção do sistema proposto. Os objetos são abstrações de conceitos do domínio de aplicação do mundo real.

O coração de qualquer AOO é o processo denominado de modelagem de informações. Na modelagem AOO, os autores consideram como parte difícil do problema estabelecer o que são as coisas do mundo real.

No caso de métodos orientados a objetos, tem sido dada mais ênfase na modelagem de informações como um procedimento formal dentro do processo de Engenharia de software (YOURDON, 1998).

A figura 3 apresenta um exemplo de aplicação da modelagem AOO com o uso da notação de Edward Yourdon. Serão representadas as entidades envolvidas em um domínio de prestação de serviços por assinatura, como uma assinatura de tv fechada, uma assinatura telefônica etc.

O exemplo apresenta somente alguns atributos e alguns serviços de um domínio de aplicação qualquer.

20

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Assinante

Id_assinanteDet_assinanteId_endereco

Entrar_assinanteInformar_endereco

Assinatura

Id_assinaturaEstado_assinaturaDetalhes_assinatura

Entrar_assinatura

1 1

Figura 3 – Exemplo de uma aplicação da AOO

Após a modelagem completa do sistema com todas as entidades, seus atributos, seus serviços e suas estruturas comportamentais definidas (relacionamentos), deve ser construído o Projeto Orientado a Objetos (POO), como uma extensão do modelo AOO.

Na proposta de Edward Yourdon, o modelo POO contém as mesmas cinco camadas e usa a mesma notação do modelo AOO, mas é estendido para conter: componente de interação humana (interface homem x máquina), componente de gerenciamento de tarefas e componente de gerenciamento de dados.

O componente de interação humana modela a tecnologia de interface que será usada para uma implementação específica do sistema.

O componente de gerenciamento de tarefas especifica os itens operacionais que serão estabelecidos para implementar o sistema. Finalmente, o componente de gerenciamento de dados define aqueles objetos necessários para interfacear com a tecnologia de banco de dados que está sendo usada.

Além da abordagem de Edward Yourdon, outros métodos e modelagens orientadas a objetos apareceram desde a década de 1970 até 1995. A seguir, algumas das iniciativas desse período:

• Sally Shlaer e Steve Mellor escreveram livros sobre análise e desenho orientado a objetos no final da década de 1980 e início da década de 1990.

• Jim Odell e James Martin basearam seus enfoques na longa experiência adquirida por ambos no uso e divulgação da Engenharia da informação. Em 1994 e 1996, lançaram 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 laboratórios da General Electric, que o levou ao livro sobre métodos chamados OMT (Object Modeling Technique) em 1991.

21

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


• Grady Booch desenvolveu um método na Rational Software para análise 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 experiência em sistemas na Ericson e desenvolveu o método OOSE (Object-Oriented Software Engineering), que se tornou a base do processo UP e do processo RUP.

Toda a proposta está na procura da independência de tecnologia e, portanto, a busca da reusabilidade. Se um dia for necessário trocar a tecnologia envolvida com as interfaces GUI por outra tecnologia mais atual, seria necessário substituir apenas o componente de interação humana.

A história da OO inicia-se no final da década de 1960, com a linguagem Simula, que foi projetada por Kristen Nygaard e Ole-Johan Dahl no centro de computação norueguês, em Oslo.

No início da década de 1970, os cientistas da computação Edsger Dijkstra e David Lorge Parnas trabalharam no conceito de programação modular, que é um importante elemento da programação orientada a objetos nos dias de hoje.

Também na década de 1970, surge a linguagem Smalltalk:

• Uma linguagem de programação orientada a objeto fracamente tipada. Em Smalltalk, tudo é objeto: os números, as classes, os métodos, os blocos de código etc.

• Não há tipos primitivos, ao contrário de outras linguagens orientadas a objeto. Strings, números e caracteres são 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 aplicações para imitar (ou simular) o mundo real. Essas classes de objeto são organizadas hierarquicamente, de modo que seja possível fazer novos objetos com características de outros objetos, com poucas mudanças.

• A linguagem Smalltalk foi desenvolvida por Adele Goldberg e Alan C. Kay.

No final da década de 1970, surge a linguagem ADA:

• Ada é uma linguagem de programação estruturada, de tipagem estática, é uma linguagem imperativa, orientada a objetos, e é uma linguagem de alto nível, 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 década de 1970, com o intuito de substituir as centenas de linguagem de programação usadas pelo DoD.

22

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

• Ada é uma aplicação com compiladores validados para uso confiável em missões críticas, tais como softwares de aviação. Normatizada internacionalmente pela ISO, sua versão mais atual é de 2005.

Em meados de 1980, o cientista da computação dinamarquês Bjarne Stroustrup criou a linguagem C++ e, dessa forma, é conhecido como o pai da linguagem de programação C++.

Stroustrup também escreveu o que muitos consideram a obra padrão de introdução à linguagem, A linguagem de programação C++, que se encontra na terceira edição. A obra possui revista para refletir a evolução da linguagem e o trabalho do comité de padrões 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 título é Object-oriented Software Construction, que se tornou um clássico na área da tecnologia OO. O livro, apesar de ser de 1988, já apresenta um conjunto de conceitos sobre a reusabilidade, técnicas de projeto, programação orientada a objetos e a aplicação das técnicas OO em outros ambientes de desenvolvimento.

1.6 Conceitos básicos da orientação a objetos

Os objetos podem ser vistos como blocos de construção que, combinados por meio de técnicas apropriadas, produzem um sistema.

Análise/Projeto/

Construção

Blocos de construçãoBlocos de rotinas/métodos

Técnicas adequadas de análise e projeto

Sistemas

Figura 4 – Objetos vistos como blocos de construção

23

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


A tecnologia OO apresenta diversos conceitos fundamentais para seu entendimento e aplicação (FURLAN, 1998):

• Objeto: um objeto é uma ocorrência específica (instância) 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 coleção de dados relacionados com um tema em comum.

Uma pessoa é um objeto, um veículo é um objeto, um documento é um objeto.

Outros conceitos sobre objeto:

— Objeto é uma bolha de inteligência que sabe agir numa determinada situação (Steve Jobs).

— Objeto é alguma coisa que faz sentido no contexto de uma aplicação, dependente do nível de abstração do desenvolvedor do sistema.

— Objetos são a base da tecnologia orientada a objetos.

— Objetos podem representar coisas do mundo real: carro, gato, máquinas etc.

— Entidades conceituais: conta bancária, compras, pedido etc.

— Coisas visuais: polígonos, pontos, retas, letras, formulários etc.

— Objeto é um conceito, uma abstração, algo com limites nítidos e significado com relação ao problema em causa (James Rumbaugh).

• Abstração: abstração consiste na seleção que se faz de alguns aspectos do problema em questão, ignorando-se outros aspectos.

— Qualquer objeto real pode ser abstraído para filtrar seu estado e comportamento.

— O estado de um objeto é determinado pelo seu conjunto de atributos (dados), e seu comportamento é definido pelos seus serviços (métodos).

– Exemplos de objetos de informática: label, botão, caixa de texto, de diálogo etc.

– Exemplos de objetos de negócio: funcionário, departamento, produto etc.

• Mensagem: objetos se comunicam a partir da troca de mensagens, isto é, um sinal enviado de um objeto a outro, requisitando um serviço por meio da execução de uma operação do objeto chamado.

— A interface lógica entre objetos é feita a partir da passagem de mensagens.

24

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

— As mensagens ocorrem apenas entre objetos que possuem uma associação.

— Todo o processamento da OO é ativado por uma implementação de mensagens que reforça o conceito de baixo acoplamento em sistemas orientados a objetos.

— A recepção de uma mensagem causa a invocação de uma operação no recebedor (objeto alvo). Esse executa o método da classe que corresponde àquela operação.

— Uma mensagem pode tomar várias formas: procedure, passagem de sinal entre “threads” ativas, acionamento específico de um evento etc.

— Um determinado objeto, recebendo uma mensagem, executará uma ação específica como resposta, alterando seu estado interno, enviando mensagens a outros objetos, criando novos objetos etc.

Objeto o1

Objeto o2

Objeto o3

Objetocliente para o2

Objetocliente para o3

Objetoservidor para o2Mensagem

de o1 para o2

01

aeronave Flap

aterrisar ajustar ânguloObjeto aeronave

Flap 1Objeto Flap

Flap ajustado

Ângulo

Nome da mensagem

02

Figura 5 – Troca de mensagens entre objetos

— A mensagem indica uma solicitação 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 parâmetros de chamada e resposta também são chamados objetos (tudo é objeto).

25

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


• Polimorfismo: é o poder que uma operação de um objeto tem de assumir vários comportamentos dependendo da chamada recebida, tratando e devolvendo respostas específicas 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 poupança, saldo do fundo de ações, saldo de renda fixa etc.

— Então, a operação “buscar_saldo” vai buscar o saldo dependendo do tipo ou parâmetro da chamada, tendo várias lógicas diferentes para um mesmo comportamento denominado “buscar_saldo”.

• Classe: classe é uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações.

— Representa uma idéia ou um conceito simples e categoriza objetos que possuem propriedades similares, configurando-se em um modelo para a criação de novas instâncias.

— É uma abstração das características 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 (operações, métodos), mesmos relacionamentos com outros objetos e mesma semântica em um domínio de aplicação.

— É como se fosse um molde para criação 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 instância 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 “instância de objeto”.

— Para nos referirmos a um grupo de coisas semelhantes, usaremos “classe de objetos”.

— Os objetos de uma classe compartilham um objetivo semântico comum, além dos requisitos de atributos e comportamentos.

26

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Cavalo Celeiro

Classe Classe

Figura 6 – Exemplo de classe de objetos

— Embora um celeiro e um cavalo tenham ambos um preço e uma idade, podem pertencer a classes diferentes.

— Caso sejam vistos, no problema, apenas como bens contábeis, poderiam pertencer à mesma classe.

• Herança: é a capacidade de um novo objeto tomar atributos e operações de um objeto existente, permitindo criar classes complexas sem repetir código. A nova classe simplesmente herda seu nível base de características de um antepassado na hierarquia de classe.

— O propósito principal do uso de herança é construir estruturas que possam ser estendidas em muitas formas diferentes. Esse enfoque pragmático pode-se completar considerando os propósitos de reusabilidade a vários níveis e os propósitos 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 situação diferente da original para o qual foi criado, reduzindo e simplificando esforços (MATICH e CARVALHO, 1992).

— A herança tem implicitamente um propósito de reusabilidade, já que proporciona uma forma de reaproveitar características capturadas por componentes, seja na forma de objetos, tipos ou classes.

• Atributo ou propriedade: característica particular de uma ocorrência da classe, por exemplo: o aluno possui nome, sexo, data de nascimento, número de registro, telefone etc.

— Característica que um objeto possui. Exemplo: nome, cor, altura, data de nascimento etc.

— Conjunto de propriedades de um objeto que definem o seu estado.

– Propriedades estáticas: mantêm o mesmo valor durante toda a sua existência (exemplo: data de nascimento de uma pessoa).

– Propriedades dinâmicas: podem ter valores que variam com o passar do tempo (exemplo: salário de um funcionário).

• Encapsulamento: combinação de atributos e operações em uma classe. Exemplo: classe “aluno”, com atributo “nome” e operação “altera_nome_aluno”.

27

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


— É a capacidade que possuem os objetos de incorporar tanto as estruturas de dados que os determinam, como as operações aplicáveis a essas estruturas em único bloco de organização e só permitir o acesso a elas por meio de métodos determinados.

— Vantagens do encapsulamento:

– Esconder (ocultar) a complexidade do código.

– Não é necessário conhecer como a operação é feita para poder utilizá-la, o código é oculto do usuário.

– Proteger os dados, permitindo o acesso a eles apenas a partir de métodos, evita que seus dados sejam corrompidos por aplicações externas.

• Generalização: atributos e operações comuns, compartilhados por classes em uma hierarquia “pai-e-filho”, ou superclasse e subclasses, ou classe “pai” e classes “filho”.

• Instância de classe: uma ocorrência específica de uma classe. É o mesmo que objeto. “José Carlos Filho” é uma instância da classe aluno, já que o “José Carlos Filho” é aluno cadastrado no sistema acadêmico da escola.

— Classes fabricam instâncias sob requisição. Esse processo é chamado instanciação.

Uma classe

Um objeto

Outro objeto

E outro objeto

Instanciação

Aeronave

Figura 7 – Instanciação

— O projetista/programador cria a classe. Em tempo de execução, a classe pode ser solicitada para criar novos objetos.

— Uma classe possui dados/atributos ou variáveis (programação), serviços/operações ou métodos (programação).

– 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.

28

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

— Uma instância (um membro) de uma classe também possui: dados/atributos ou variáveis de instância e operações/métodos de instância.

– Exemplo: cor, peso e ano de fabricação são atributos de instância da classe “carro”.

— Cada atributo de instância possui um valor para cada instância de objeto. O nome de um atributo é único dentro de uma classe.

— O agrupamento de objetos em classes permite a abstração de um problema.

— As definições comuns e as operações de cada instância são descritas somente uma vez na classe, e os objetos da classe podem beneficiar-se da reutilização das definições armazenadas.

• Operações: lógica contida em uma classe para designar-lhe um comportamento. Exemplo: calcular a idade de um aluno dada a sua data de nascimento.

— Operação é uma função ou transformação que pode ser aplicada a objetos ou por esses a uma classe em uma determinada situação.

– Exemplo: alterar sua cor, mostrar uma janela, debitar um valor, aceitar o crédito de um cliente.

— Todos os objetos da classe compartilham as mesmas operações.

— Método é a implementação de uma operação para uma classe.

— O ato de invocar um método também é chamado de “passar uma mensagem para o objeto”.

— Toda classe possui um método denominado “construtor”: atribui valores às propriedades de um objeto quando esse é criado. É o método de inicialização de um objeto instanciado.

— Em Java o método construtor possui sempre o mesmo nome da classe.

• Subclasse: característica particular de uma classe. Exemplo: classe “animal”, subclasses “gato”, “cachorro” etc.

2 A LINgUAgEM UNIfICADA DE MODELOS (UML)

2.1Introdução

Antes da UML, havia uma diversidade imensa e improdutiva de abordagens de modelagem, e sua convergência na UML 1.0 foi um passo à frente significante na utilização de modelos no desenvolvimento de software.

Cada desenvolvedor usava a abordagem do autor de sua preferência, que nem sempre convergiam suas opiniões em torno do tema. Outro problema era a proliferação de ferramentas gráficas específicas

29

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


para uma determinada notação para uma metodologia OO também específica e, na maioria das vezes, proprietárias.

Ivar Jacobson, Grady Booch e Jim Rumbaugh, em 1995, tomaram a iniciativa de unificar os métodos OOSE (Object Oriented Software Engineering), o método Booch’93 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 versão 1.3, a UML passou a ser mantida pela OMG (Object Management Group), que é um grupo americano responsável pela padronização do uso da orientação a objetos nos Estados Unidos.

A UML firma-se então no mercado e passa a ser um padrão internacional para a especificação e modelagem de sistemas aplicativos em todas as áreas de abrangência da área de informática ou TI (Tecnologia da Informação).

A finalidade da UML é proporcionar um padrão para a especificação e arquitetura de projetos de sistemas, desde os aspectos conceituais até as soluções concretas, tais como, as classes de objetos, esquemas de banco de dados e componentes de software reusáveis (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 próprio tipo de projeto e para seu próprio processo, usando a UML para registrar os resultados de suas decisões de análise e design.

Lembrete

A garantia de ser um padrão internacional levou a UML a ser adotada pela OMG que especifica e mantém o metamodelo UML.

A especificação 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 técnicas de especificação formal.

Por outro lado, enquanto essa abordagem usa o rigor de um método formal de especificação, também oferece a vantagem de ser mais intuitivo e pragmático para a maioria dos implementadores e praticantes.

30

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

O metamodelo da UML foi projetada com os princípios de design flexível, tendo em mente o seguinte:

• Modularidade: o princípio da forte coesão e baixo acoplamento é aplicado para a construção 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 específicas (por exemplo, (J2EE/EJB, .NET / COM +) e domínios (por exemplo, finanças, telecomunicações, aeroespacial).

— Uma nova linguagem relacionada à UML pode ser especificada por reutilizar parte do pacote e bibliotecas de “InfraEstrutura” dessa.

• Reutilização: a biblioteca do metamodelo é flexível para permitir que seja reutilizada para definir o metamodelo UML, bem como outros metamodelos arquitetônicos 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 associação internacional, aberta, sem fins lucrativos e um consórcio da indústria de computador desde 1989.

Qualquer organização pode participar da OMG e dos processos de definição das normas. A política da OMG garante que todas as organizações, grandes e pequenas, tenham uma voz eficaz no seu processo.

A associação inclui centenas de organizações, sendo metade de softwares finais e a outra metade representando praticamente todas as organizações da indústria 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 contém os elementos do modelo. Esses são criados instanciando-se os elementos do modelo a partir de um metamodelo. O papel típico de um metamodelo é definir a semântica 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 “Associação” são ambas definidas como parte do metamodelo UML.

31

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Essas são instanciadas em um modelo de usuário ou desenvolvedor, de modo que as classes “Pessoa” e “Carro” são as duas instâncias da metaclasse “Classe”, e a associação entre as classes é um exemplo da metaclasse “Associação”.

A Figura 8 mostra todos os relacionamentos entre o metamodelo e o modelo do sistema que está sendo desenvolvido.

Classe Associação

Pessoa Carro

MetalmodeloUML

Modelo do sistema

“InstânciaDe”

Figura 8 – Exemplo de metamodelagem (note que todos os relacionamentos são mostrados no diagrama)

A semântica da UML define o que acontece quando o usuário define os elementos que são instanciados em seu modelo.

Saiba mais

Na atualidade, a UML encontra-se na versão 2.3 e é composta de 13 diagramas. A especificação formal da UML 2.3 pode ser encontrada no endereço <www.omg.org/spec/UML/2.3/>.

Quadro 1 – Diagramas da UML

Diagramas

Número UML 1.X UML 2.3

1 Atividade Atividade

2 Caso de uso Caso de uso

3 Classe de objetos Classe de objetos

4 Objetos Objetos

5 Sequência Sequência

6 Colaboração Comunicação

7 Estado Estado

8 Componentes Componentes

9 Implantação Implantação

10 ------------- Pacotes

11 ------------- Interação

12 ----------- Tempo

13 ---------- Estrutura composta

32

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

A proposta da UML não é 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 propõe modelos para a fase de especificação, outros modelos para a fase de design e modelos para o momento de se definir as lógicas dos programas ou transações.

Todas essas formas ou modelos obedecem às regras e fundamentos da orientação a objetos na construção de softwares.

Conforme Medeiros (2004), apesar da definição dos três amigos, pode-se dizer que a UML é uma forma de comunicar uma idéia, e busca um padrão para a ciência da computação com relação à comunicação de pessoas da área, e não uma linguagem de computador.

A UML não é um processo de desenvolvimento, tais como, o modelo cascade, ou o modelo RUP (Rational Unified Process), ou o processo ágil SCRUM. É uma linguagem de comunicação 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 aplicável a diversos tipos de sistemas, dos mais simples até os mais complexos.

Além disso, a UML é não proprietária e aberta a todos. Com a aprovação da UML em novembro de 1997 pela OMG, a guerra de métodos OO havia chegado ao seu final.

De acordo com a UML, ela pode ser usada para:

• Mostrar as fronteiras de um sistema e suas funções principais. Aqui se introduziu os conceitos de atores e casos de uso.

• Ilustrar a realização de casos de uso com diagramas de interações.

• Representar uma estrutura estática de um sistema utilizando diagramas de classes.

• Modelar o comportamento de objetos com diagramas de transição de estado.

• Revelar a arquitetura de implementação física com diagramas de componentes e de implantação (deployment).

• Estender sua funcionalidade a partir de estereótipos.

2.2 A UML e o Processo Unificado

Para se falar de um processo de software, é necessário alguns conceitos envolvidos com a Engenharia de software.

33

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


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 produção de software de qualidade.

• A Engenharia de software estuda processos, modelos e metodologias de desenvolvimento, a gerência de projeto de software, investigação de novos métodos, ferramentas e teorias correlatas, tais como, a qualidade e a produtividade.

• Envolve a escolha seletiva de métodos e ferramentas adequados para o atendimento de um determinado contexto (restrições) de sistema de computação.

• Abrange todo o ciclo de vida do software, desde a especificação inicial do sistema até sua operação e manutenção.

A Engenharia de software está baseada em pilares que lhe dão sustentação. A figura 9 mostra um esquema dessa visão da ES.

Engenharia de software(s)

Processos/guias/práticas/metodologias

Técnicas métodos métricas

Qualidade/produtividade

Gerência governança

Ferramentas

Figura 9 – Pilares da Engenharia de software

O estudo dos métodos/técnicas/métricas definem a sequência, a simbologia e os padrões em que as atividades devem ser aplicadas no desenvolvimento e manutenção de software.

Com relação às ferramentas, a ES estuda e propõe a automatização dos métodos e técnicas. Essas ferramentas de software são 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 construção de softwares de qualidade. Com as ferramentas, procura-se também a melhoria da produtividade das equipes de desenvolvimento.

A gestão/gerência/governança inclui o planejamento de projetos, controle dos projetos, alocação 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 estratégias empresariais.

34

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Dentro dessa abrangência 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 Ciência da Computação, Sistemas de Informação e Engenharia da Computação e cobre todo ciclo de vida de um sistema ou software.

Os principais livros adotados pelos cursos são: 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 prática, de James F. Peters e Witpçd Pedrycz, editado pela Editora Campos; e o Livro Engenharia de software fundamentos, métdos e padrões, de Wilson de Pádua Paula Filho, editado pela LTC.

Mas, o que é um processo de software?

• Um processo de software é um conjunto estruturado de atividades (ou fases) necessárias para produzir um produto de software.

• Um processo de software completo abrange as grandes fases de especificação, design ou projeto, a implementação e a manutenção ou evolução do software.

• Os processos de software são organizados segundo diferentes modelos de desenvolvimento.

Quais são os modelos ou processos de software mais conhecidos?

• Ao longo do tempo, desde a década de 1960, a Engenharia de software desenvolveu diferentes representações abstratas das fases de um processo de software e suas interdependências.

• Os modelos mais representativos e utilizados na Engenharia de software são:

— Modelo cascata (ou clássico):

– O paradigma do ciclo de vida clássico ou cascade demanda uma abordagem sistemática e sequencial para o desenvolvimento de software.

– Começa em termos de sistema e progride por meio da análise, design, codificação, teste e manutenção.

35

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


– A figura 10 mostra um esquema visual do modelo cascade ou cascata.

Engenharia de Sistemas

Análise

Design

Codificação

Teste

Manutenção

Figrura 10 – Ciclo de vida clássico

– Todavia, os projetos reais raramente seguem um fluxo sequencial que o modelo propõe. Ocorrem interações, voltas a níveis anteriores, provocando problemas na aplicação do paradigma clássico.

– Frequentemente, os usuários têm dificuldade de estabelecer explicitamente todos os requisitos do software, acompanhados das incertezas naturais que existem no início de muitos projetos.

– Os usuários tem que ser muito pacientes. Uma versão do software somente estará disponível quando todo o sistema for definido e desenvolvido. Qualquer alteração pode ocasionar um desastre no desenvolvimento do sistema.

– Esses problemas são reais, porém o paradigma do ciclo clássico de software tem um definitivo e importante lugar na Engenharia de software, pois ele proporciona um modelo real para o uso dos métodos para analisar, projetar, codificar, testar e manter softwares.

— Espiral:

– O modelo espiral para a ES foi desenvolvido para abranger as melhores características do ciclo clássico, adicionando um novo elemento chamado análise de risco.

– O modelo apresenta quatro grandes atividades:

– Planejamento: determinação dos objetivos, alternativas e requerimentos.

– Análise de risco: análise das alternativas e identificação e resolução dos riscos.

36

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

– Engenharia: desenvolvimento do próximo nível do produto.

– Avaliação do cliente: aceite dos resultados da Engenharia.

– O modelo espiral desenvolve o software passo a passo. Cada novo ciclo pressupõe um maior detalhamento do software, sua construção por meio ou não de prototipagem e um uso real para aceite dos usuários.

– A cada final de ciclo e início de outro, os riscos são avaliados e o projeto pode ser ou não cancelado. O número de ciclos não pode ser alto, pois poderia colocar em risco o modelo.

– O ciclo final é utilizado para incorporar a parte de segurança, 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.

Observação

Todos os modernos processos de software, inclusive os métodos ágeis, consideram a iteratividade e a liberação parcial de um projeto em suas propostas metodolóicas, conceitos oriundos do modelo espiral.

— 4GL – técnicas de quarta geração:

– O termo “técnicas de quarta geração” (4GL) abrange um conjunto de ferramentas de software que possuem alguma coisa em comum.

– Permitem ao desenvolvedor especificar algumas características do software em alto nível de abstração e então geram automaticamente códigos fontes baseados nas definições.

– Os principais ambientes que suportam o paradigma 4GL são: linguagens não procedurais para pesquisas em banco de dados, geradores de relatórios, manipuladores de dados, definidores de telas interativas, geradores de código, geradores de gráficos, arquitetura MDA etc.

– Idêntico aos outros paradigmas, o 4GL começa com a especificação dos requisitos junto aos usuários, que deverão ser transportados para um prototipador. Os códigos gerados deverão ser testados e aprovados para que o sistema possa ser considerado pronto.

– As técnicas de quarta geração têm se tornado uma parte importante da ES, principalmente na área de sistemas de informação gerenciais. O que se ve é uma diminuição cada vez maior no uso de métodos tradicionais no desenvolvimento de sistemas, e o crescimento no uso das técnicas de quarta geração.

37

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


2.2.2 Os processos denominados de ágeis

Os processos ágeis ou a modelagem ágil é um processo baseado nas práticas que descrevem como um modelador ágil deve agir.

A motivação é devido às estratégias atuais ou clássicas de modelagem que, muitas vezes, não se mostram funcionais ou são consideradas muito pesadas e burocráticas.

Em um extremo, a modelagem não existe; do outro, se produz modelagem em excesso.

De acordo com Scott W. Ambler, a modelagem ágil se propõe a encontrar um meio termo, o qual permita uma modelagem suficiente para explorar e documentar um sistema de modo eficaz, mas não a ponto de tornar isso um fardo e fatalmente torná-lo um fracasso.

As técnicas da modelagem ágil podem e devem ser aplicadas por equipes de projetos que desejam empregar uma estratégia ágil de desenvolvimento de software.

Os principais frameworks ou modelos ou métodos ágeis da atualidade são: 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 páginas 59 a 76, faz uma abordagem sintética sobre os métodos ágeis que ele denomina de desenvolvimento ágil, que se inicia com a discussão do que é agilidade, passa pelos conceitos de um processo ágil e apresenta os principais modelos ou métodos ágeis em uso no âmbito internacional, tais como: a Extreme Programming (XP), o Scrum, o Crystal, o FDD (Desenvolvimento Guiado por Características) 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 concepção, de elaboração, de construção e de transição.

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.

38

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

Phases

Inception

I1 E1 C1 T1 T2C2 Cn

Elaboration Construction Transition

Configuration management

Model

ImplementationTest

Deployment

Environment

Project management

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

A fase inception seria a fase de concepção, a fase Elaboration seria a fase de elaboração, a fase Construction é a fase de construção e a fase Transition é a fase de transição.

Na fase de concepção, se definem os requisitos do software e se avalia a tecnologia necessária para uma solução aderente às necessidades do cliente. Nesse ponto, também é 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 nível mais abstrato, já que não se pode demorar muito para se fazer uma proposta comercial e técnica ao cliente envolvido.

Na fase de elaboração, na qual para a UP se detalham os requisitos, a UML apóia com diversos diagramas e modelos (disciplina Model), tais como: o modelo de casos de uso com os cenários detalhados, diagrama de atividades (para especificações visuais de lógicas mais complexas), diagramas de estado, diagrama de classes em nível de domínio e outros que se fizerem necessários para deixar as especificações suficientes para a implementação.

A fase de construção é quando se pensa em protótipos, em banco de dados e lógicas de programação.

A UML, nessa fase, contribui com os diagramas de sequência, comunicação, tempo, pacotes, implantação e componentes.

Se o processo é iterativo e incremental, no qual o software não é liberado todo de uma única vez, mas desenvolvido e liberado em pedaços, a fase de construção consiste de muitas iterações, em que constrói-se software, testa-se e faz-se a integração que satisfaça um conjunto de requisitos do projeto.

Já na fase de transição, estamos falando dos testes e homologação, dos quais a UML não possui diagramas ou modelos de suporte diretamente.

39

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


Resumo

Este capítulo apresentou um histórico e conceitos da modelagem de software e o histórico da linguagem de modelos UML.

Modelar sistemas é a capacidade de simplificar a complexidade inerente aos sistemas de informação.

A construção de modelos permite se enxergar o todo antes de se iniciar a construção ou programação 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, não uma metodologia de desenvolvimento de software.

A UML define uma notação e um metamodelo. A notação é o material gráfico visto em modelos, é a sintaxe da linguagem de modelagem.

Ainda sobre a tecnologia orientada a objetos:

• As técnicas baseadas em objetos simplificam o projeto de sistemas complexos.

• A tecnologia de objetos visualiza os sistemas como uma coleção de objetos, cada um deles em um determinado estado, dentre muitos estados existentes.

• A revolução na indústria de software indica um movimento em direção a uma era em que os softwares serão montados a partir de componentes reutilizáveis.

• Os componentes serão criados a partir de componentes existentes, e serão criadas grandes bibliotecas desses componentes.

40

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

• Novamente, discute-se com bastante veemência o conceito das caixas-pretas, cujo interior não enxergamos, apesar de sabermos o que elas fazem ou produzem.

• As técnicas baseadas em objetos sozinhas não podem prover a magnitude da mudança necessária. Elas têm de ser combinadas com outras tecnologias.

• As tecnologias ditas otimizadoras são:

— ferramentas Case;

— programação visual;

— geradores de código;

— repositório central de dados e módulos/componentes;

— metodologias baseadas em objetos;

— banco de dados orientado a objetos;

— linguagens não procedurais;

— métodos formais baseados na matemática;

— tecnologia cliente-servidor, aplicativos orientados a serviços (SOA);

— bibliotecas de classes que maximizem a reusabilidade;

— abstração de modelos mais próximas do mundo real.

Exercícios

Questão 1. Os autores que trabalham os conceitos envolvidos com os objetivos da Engenharia de software afirmam que ela é a aplicação de teoria, modelos, formalismos, técnicas e ferramentas da ciência da computação e áreas afins para o desenvolvimento sistemático 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 construídos em padrões 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 métodos, as técnicas e as ferramentas também

41

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12


apoiam o gerenciamento do processo de desenvolvimento, devido principalmente a criação de uma documentação formal, que é destinada à comunicação entre os membros da equipe e aos usuários do sistema.

Considerando os conceitos sobre o uso de modelos no desenvolvimento de software, analise as afirmações 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 realização de conversas ricas em aprendizados.

B) Como os modelos possuem uma sintaxe precisa, geralmente são melhor utilizados com o apoio de uma ferramenta gráfica, que, por conter semânticas que determinam como os conceitos específicos de domínio são aplicados, diminuem consideravelmente os erros cometidos no processo de desenvolvimento.

C) Como os modelos aplicados na Engenharia de software podem abstrair e agregar informações de uma série de artefatos, eles podem ser utilizados para as verificações de consistência e para a garantia da qualidade.

D) Um modelo pode ser considerado um meio de comunicação entre as pessoas envolvidas em um projeto. Também ajuda outros indivíduos, que podem utilizá-lo como base para a sua implementação ou para a concepção de novos modelos.

E) Os modelos, no processo de desenvolvimento de software, somente possuem características de comunicação e não conseguem apoiar a equipe na melhoria contínua de seus processos.

Resposta: Alternativa E.

A modelagem de sistemas de informação ou sistemas de software é uma atividade que, a partir da construção de modelos, consegue explicar as características ou o comportamento de um aplicativo ou de um sistema de software. No processo de desenvolvimento e construção de um software, os modelos podem ser usados na identificação das características e funcionalidades que o software deverá prover e no planejamento de sua construção.

Análise das alternativas

A) Correta. Quando se defronta com um problema, o homem desenvolve mentalmente uma série de abstrações, as quais permitem o encaminhamento de soluções. Essas abstrações da realidade são denominadas modelos.

B) Correta. Os modelos são acompanhados de padrões no seu uso e possuem uma semântica bem definida. As ferramentas denominadas CASE incluem esses padrões, conseguindo, assim, orientar e diminuir os possíveis erros que possam ser cometidos pelas pessoas.

42

Unidade I

Revi

são:

Virg

ínia

- D

iagr

amaç

ão: M

árci

o -

14-0

8-20

12

C) Correta. A qualidade de software pressupõe que os artefatos produzidos no ciclo de desenvolvimento devem ser verificados passo a passo, para que se tenha uma consistência nos produtos realizados. Como os modelos representam graficamente os produtos de software, possibilitam revisões mais cosistentes pelos participantes de seu processo de construção.

D) Correta. Como um modelo representa uma abstração de uma realidade, outros podem ser construídos para uma solução de novos aspectos envolvidos com aquela realidade. Um modelo também pode ser detalhado com o uso de novos modelos mais específicos dentro da realidade observada.

E) Incorreta. Os modelos no processo de desenvolvimento são utilizados por todos os envolvidos no sistema e são considerados como uma forma de entendimento e apoio às atividades do processo de desenvolvimento, que, a partir da avaliação dos problemas encontrados, pode proporcionar a melhoria do processo.

Questão 2. A Orientação a Objetos é considerada um paradigma para o desenvolvimento de software. Baseia-se na utilização de componentes individuais (chamados de objetos), que colaboram para construir sistemas mais complexos. Toda a comunicação ou colaboração entre os objetos é feita por meio do envio de mensagens (um objeto aciona outro objeto para a execução de uma operação 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 Orientação a Objetos, analise as afirmações a seguir e assinale a alternativa incorreta:

A) Dentro da tecnologia OO, um objeto é alguma coisa que faz sentido no contexto de uma aplicação e representa uma entidade relevante para o entendimento e para a solução de uma necessidade de uma atividade ou ao usuário do sistema.

B) Como na OO os objetos se comunicam por meio de mensagens, uma mensagem enviada por um objeto causa a ativação de uma operação (método) no objeto alvo para responder ao chamado do objeto ativador ou chamador.

C) Na OO, o conceito de polimorfismo surge quando uma operação de um determinado objeto atua de acordo com as definições específicas de sua funcionalidade.

D) Para ser utilizada, uma classe de objeto precisa de um método denominado Construtor, que inicializa o objeto quando ele é instanciado e disponibiliza os recursos para que sejam utilizados pelos métodos ou operações do objeto.

E) A UML (Unified Modeling Language) foi desenvolvida na década de 1990 para unificar as diversas correntes existentes no desenvolvimento de software que utilizavam a tecnologia da Orientação a Objetos.

Resolução desta questão na Plataforma.

modelagem de processos unidade i

Documents