Curso de Java Módulo Básico

Transcrição

1 UNIJUI Universidade Regional do Noroeste do Estado do Rio Grande do Sul Ijuí, RS Campus Ijuí DETEC Departamento de Tecnologia Curso de Java Módulo Básico Introdução à OO Introdução à UML Introdução à JAVA Eleonor Vinicius Dudel Mayer Agosto de

2 Sumário 1.Introdução à Orientação a Objetos Objetos Classe Polimorfismo Herança Métodos orientados a objetos Introdução à UML Origem e evolução da UML Diagramas na UML Diagrama de Caso de Uso Diagrama de Interação Diagrama de Seqüência Diagrama de Colaboração Diagrama de Gráfico de Estados Diagrama de Atividades Diagrama de Classes Diagrama de Componentes Diagrama de Objetos Diagrama de Implantação Como os diagramas se relacionam na UML Elementos da UML Blocos de construção da UML Itens Itens Estáticos Classe Colaboração Caso de Uso Componente Itens Dinâmicos Iteração Máquina de Estados Pacotes Notas Relacionamentos Associação Multiplicidade de associação Agregação e Composição Generalização Especialização Realização Propósitos da UML O que não é UML

3 2.13.Onde pode ser utilizada a UML Diferenças entre as versões da UML Versão 1.0 para Versão 1.1/1.2 para Modelagem utilizando a UML Modelagem da arquitetura de sistemas A importância da modelagem Construindo modelos Modelagem orientada a objetos Introdução à JAVA Kit de Desenvolvimento JAVA Plataforma JAVA Java Virtual Machine (JVM) Java 2 JDK Compilador javac Interpretador java Interpretador jre Gerador de documentação javadoc Java Archieve Tool Sintaxe Nomes de identificadores Palavras reservadas Operadores da linguagem JAVA Precedência de operadores Tipos Primitivos Java e C JAVA Básico Comandos Declaração de variáveis Condicionais Laços Comandos especiais Comentários Modificadores Declaração de classes, métodos e variáveis Classes Subclasses Interfaces Instanciação de objetos super e this Conversões Tipos Primitivos Objetos Interfaces Arrays Aplicação JAVA Parâmetros de entrada

4 4.3.9.Exceções Threads Criação de threads Métodos de tread Monitores Uso de wait() e notify() JDBC Arquitetura JDBC Instalação de um driver JDBC Exemplo com a ponte JDBC ODBC Classes do package java.sql Tabela de conversão JAVA SQL RMI Remote Method Invocation Arquitetura RMI Interface com métodos de acesso remoto Servidor de métodos Cliente Etapas de compilação Inicio do serviço

5 1. Introdução à Orientação a Objetos A orientação a objetos surgiu como uma nova forma de modelar e construir sistemas de software, isto é, organizar e gerir conhecimentos manipulados e registrados dentro de uma empresa. No desenvolvimento de um sistema orientado a objetos, dados e processos são organizados e manipulados por objetos, e não por programas. Vantagens: Reutilização dos objetos: Os dados e os processos são manipulados por objetos, não ficando engessados dentro de programas, isto é, os objetos construídos podem ser utilizados por diferentes sistemas; Modularidade: O sistema é formado por objetos e não por programas, facilitando o trabalho e a manipulação desses objetos no futuro; Utiliza se dos mesmo conceitos da realidade na construção de sistemas de software. A orientação a objetos baseia se em conceitos da realidade objetos, estado e estímulos para modelagem e construção de sistema de software. Dessa forma, o uso da orientação a objetos se torna mais natural, pois os conceitos utilizados são os mesmos que já conhecemos, só que aplicados nesses casos ao desenvolvimentos de sistemas. 5

6 Exemplo de objeto, estado e estímulo 1.1.Objetos Pode ser qualquer coisa na natureza que possua características e comportamentos. Objetos: Uma pessoa; Um veículo; Uma região; 1.2.Classe É uma abstração de um conjunto de objetos que possuem os mesmo tipos de características e comportamentos. Classe Veículo: Carro de Passeio; Carro Esportivo; Carro Rural; 1.3.Polimorfismo Polimorfismo (do grego muitas formas ) refere se aos processos que vários objetos podem 6

7 executar, dado apenas a solicitação de uma única operação. No ambiente polimórfico, todos os objetos contem uma mesma operação, que é implementada por métodos particulares a cada objeto. Polimorfismo 1.4.Herança É o comportamento pelas classes especializadas (subclasses) dos atributos e operações de classes mais gerais (superclasse). Herança 1.5.Métodos orientados a objetos Nos últimos tempos houve uma grande evolução na engenharia de software, que passou a contar com técnicas, como a análise, o projetos estruturado e a Engenharia da Informação. Os métodos 7

8 orientados a objetos surgiram na década de setenta (70), procurando melhorar estas técnicas. A seguir são apresentados resumidamente alguns métodos que surgiram para a orientação a objetos. Método Booch OMT OOSE Coad/Yourdon Descrição Consiste em técnicas do desenho orientado a objetos. Esse método utiliza se do desenho de objetos, que servem como base para a criação dos módulos do sistema. Esse método foi criado por Grandy Booch. O método OMT (Object Modeling Technique) consiste na modelagem semântica de dados, suportando os conceitos de: Modelagem de dados (atributos e relacionamentos); Objetos (composição e agregação); Herança; Esse método foi criado por James Rumbaugh. O método OOSE (Object Oriented Software Engineering), consiste na análise dos requerimentos de um sistema utilizando casos de uso, criando categorias para pessoas e equipamentos com que esses casos interagem. Esse método foi criado por Ivar Jacobson. Peter Coad e Ed Yourdon dividiram a análise orientada a objetos em classes e objetos. Dentro desse contexto, os objetos são relacionados por meio dos conceitos de agregação, generalização/especialização, associação, conexões e mensagens. 8

9 2. Introdução à UML A Unified Modeling Language (UML) é o resultado da unificação dos métodos Booch, OMT e OOSE, que dá origem a uma linguagem padronizada para a modelagem de sistema de software orientados a objetos, sendo adotada pela indústria de software como linguagem padrão, e também por fornecedores de ferramentas CASE. 2.1.Origem e evolução da UML Os trabalhos para criação da UML iniciaram se em mil novecentos e noventa e quatro (1994) com Grandy Booch (Método Booch) e James Rumbaugh (Método OMT), que combinaram seus dois métodos mais populares. Versão Ano Principais Fatos Ocorridos UML Lançamento do primeiro esboço da UML. UML Integração de Ivar Jacobson à equipe, e seu método OOSE à expansão do escopo da UML. Formação de um consórcio de empresas, com o objetivo de apoiar a definição da UML. UML A UML foi submetida como candidata a linguagem padrão de modelagem à OMG (Object Management Group, uma entidade de padronização estabelecida pela indústria de software). UML Expansão do consórcio formado por empresas para apoiar a definição da UML, e aceitação da UML pela OMG. UML Revisões e novas padronizações. UML Revisões e novas padronizações. 2.2.Diagramas na UML Diagrama é a representação gráfica de um conjunto de elementos do sistema. A UML disponibiliza nove diagramas que permitem representar diferentes partes do modelo de um sistema. 9

10 2.2.1.Diagrama de Caso de Uso O diagrama de casos de uso representa um conjunto de atores, casos de uso e os relacionamentos entre eles. Diagrama de Casos de Uso Diagrama de Interação Os diagramas de interação representam colaborações entre objetos, para realizarem algum tipo de comportamento para um sistema. Os diagramas de interação são representados por: Diagrama de Seqüência; Diagrama de Colaboração; Diagrama de Seqüência O diagrama de seqüência dá ênfase à ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Podemos entender por mensagens, os serviços solicitados por um objeto a outro, e as respostas devolvidas a essas solicitações. 10

11 Diagrama de Sequencia Diagrama de Colaboração O diagrama de colaboração dá ênfase à ordenação estrutural em que as mensagens são trocadas entre os objetos de um sistema. Diagrama de Colaboração Diagrama de Gráfico de Estados O diagrama de gráfico de estados representa os estados possíveis de um objeto em particular. São 11

12 exibidos os estados de um objeto, eventos, transições e atividades. Pode ser usado principalmente para a modelagem de estados de classes e colaborações. Diagrama de Gráfico de Estados Diagrama de Atividades O diagrama de atividades representa a modelagem do fluxo de controle de uma atividade para uma outra no sistema. São exibidos os estados das atividades e ações, transições e objetos. Diagrama de Atividades Diagrama de Classes O diagrama de classes representa a estrutura (esqueleto) de um sistema, sendo encontrado 12

13 geralmente na maioria dos sistemas orientados a objetos. São exibidos classes e seus respectivos relacionamentos. Diagrama de Classes Diagrama de Componentes O diagrama de componentes representa um conjunto de componentes e suas respectivas dependências, podendo ter como base de sua construção os diagramas de classes. Diagrama de Componentes Diagrama de Objetos O diagrama de objetos representa as instâncias das classes de um sistema, em determinado ponto no tempo. 13

14 Diagrama de Objetos Diagrama de Implantação O diagrama de implantação representa a configuração e a arquitetura de um sistema em que estarão ligados os respectivos componentes, podendo ser representado também a arquitetura física de hardwares, processadores, entre outros. Com o diagrama de componentes, representa os aspectos físicos de um sistema. Diagrama de Implantação 2.3.Como os diagramas se relacionam na UML Os diagramas da UML representam diferentes partes do modelo de um sistema. No quadro a seguir é demonstrado como os diagramas se relacionam, formando toda a modelagem orientada a objetos. 14

15 Relacionamento entre diagramas da UML 2.4.Elementos da UML Os elementos da UML são as simbologias e notações que utilizaremos para construir os modelos orientados a objetos. Nesse caso, os elementos principais são os blocos de construção. 2.5.Blocos de construção da UML Os blocos de construção da UML são as matérias primas utilizadas pelos diagramas para representar partes de um sistema de software. Entre os blocos de construção existentes na UML, podemos observar: Itens; Relacionamentos; Itens Os itens são os blocos de construção da modelagem orientada a objetos. Existem quatro tipos de itens na UML. São eles: Tipo Itens Estáticos Descrição Representam a estrutura do modelo, elementos conceituais e físicos 15

16 Tipo Itens Dinâmicos Pacotes Notas Descrição (classes, colaborações, casos de uso, entre outros). Definem o comportamento do modelo (interações e estado dos objetos). São as partes organizacionais da UML. São as partes explicativas do modelo na UML (comentários e observações de esclarecimentos no modelo). 2.6.Itens Estáticos Os itens estáticos representam o esqueleto e a estrutura estável de um sistema Classe Uma classe é um conjunto de objetos que compartilham os mesmo atributos, operações e relacionamentos. É representada graficamente como no exemplo a seguir: Classe Colaboração Uma colaboração é o nome dado à interação entre duas ou mais classes, com o objetivo de fornecer algum comportamento cooperativo. Ocorrem por meio da troca de mensagens entre dois ou mais objetos. 16

17 2.6.3.Caso de Uso Um caso de uso é um documentos que descreve os cenários pretendidos para um sistema, com o objetivo de atender às necessidades do usuário. É representado graficamente como no exemplo a seguir: Caso de uso Componente Um componente é a parte física de um sistema. Existem diferentes tipos de componentes, como os componentes COM+ e Java Beans. Componente 2.7.Itens Dinâmicos Os itens dinâmicos representam as partes de um sistema que possam ter alguma alteração. Existem dois tipo principais de itens dinâmicos. São eles: Iteração; Máquina de estados; Iteração Representa a realização dos processos de um sistema, por meio da troca de mensagens entre os objetos. Pode envolver mensagens, seqüências de ações e conexões entre os objetos. Uma interação é representada por uma flecha cheia, como no exemplo seguir: 17

18 Mensagem Máquina de Estados Representa um comportamento que especifica as seqüências de estados pelos quais os objetos passam durante sua existência, de acordo com os eventos atendidos. No exemplo a seguir, temos um estado possível para o objeto Venda. Estados 2.8.Pacotes Os pacotes organizam os modelos criados na UML. Todos os blocos de construção criados no UML (casos de uso, classes, componentes, e demais), bem como os diagramas que tratam desses blocos, podem ser organizados em pacotes. Deve se fazer essa organização observando a semelhança de cada bloco e diagrama da UML, no que diz respeito à solução do problema que cada um está empregando. 18

19 Pacotes 2.9.Notas As notas representam comentários, observações e esclarecimentos que poder se utilizar para qualquer elemento da UML. No exemplo a seguir, a representação de uma nota informando a última versão de uma classe. Nota 2.10.Relacionamentos Os relacionamentos reúnem os itens criados na UML. Existem seis tipo de relacionamentos. São eles: Associação; Agregação e composição; Generalização; 19

20 Especialização; Realização; Associação Uma associação descreve relacionamentos entre objetos. Cada associação tem duas pontas, onde em cada ponta está ligado um objeto. Por exemplo, poderíamos ter um relacionamento de associação entre o objeto Cliente na primeira ponta, e o objeto AnaliseCredito na outra ponta. Associação Multiplicidade de associação É a indicação de quantos objetos podem participar de dado relacionamento. No exemplo anterior, pode se dizer que o objeto NotaFiscal pode ter um ou mais objetos Produtos, enquanto esse objeto pode ter zero ou mais objetos NotaFiscal. Na UML temos basicamente os seguintes tipos de multiplicidade: 0 (zero); 1 (um); 0..1 (zero ou um); 0..* (zero ou mais); 1..* (um ou mais); * (muitos); Agregação e Composição A agregação é um tipo de associação na qual o todo é relacionado com suas partes (um objetos todo contem os objetos partes relacionamento todo/parte). É representada como um linha de associação 20

21 com um diamante junto à classe agregadora. Agregação A composição é um tipo de relacionamento muito semelhante à agregação. Em uma composição, o objeto parte pode pertencer somente ao objeto todo. Além disso, geralmente o objeto todo vive e morre com suas partes, isto é, acontece uma remoção em cascata. É representada como uma linha de associação com um diamante preto, junto à classe agregadora. Composição Generalização Generalização é a capacidade de se criar supertipos que encapsulam a estrutura e o comportamento comum a vários subtipos. Os procedimentos pode se obter a generalização são: Identificar similaridades de estrutura/comportamento entre várias classes; Criar o supertipo para encapsular a estrutura e o comportamento comum a mais de uma classe; Os objetos originais passam a ser subtipos de novo supertipo criado; Especialização A especialização é a capacidade de se criar subtipos que representam refinamentos nos quais a 21

22 estrutura e/ou comportamento do supertipo são adicionais ou modificados. Os procedimentos para obter a especialização são: Perceber que algumas classes apresentam estrutura e/ou comportamento especializado; Criar subtipos de acordo com sua especialização; Generalização / Especialização Realização A realização é um relacionamento entre itens, em que um item implementa comportamentos especificados por outros. Pode ser realizado entre interfaces e classes ou componentes que as realizam. É representado por uma seta pontilhada, como no exemplo a seguir: 22

23 Realização 2.11.Propósitos da UML A UML nasceu com o propósito de documentar, visualizar, especificar e construir sistemas de software orientados a objetos. Propósito Documentar Visualizar Especificar Construir Descrição Artefatos como requisições de negócio, modelo de arquitetura, códigofonte, modelo de análise, protótipo e outros documentos que servem de informação sobre o sistema, podem ser documentados com a UML No processo de desenvolvimento de sistemas de software, é quase impossível a visualização de toda a estrutura de um software sem o uso de modelos que a represente. Dessa forma, a UML disponibiliza símbolos gráficos para a representação de artefatos de software. A UML é uma linguagem que atente a todos os requisitos de especificação dentro de um processo, desde a fase de análise até a fase de teste e implementação do sistema construído. Na UML é possível realizar um mapeamento dos modelos gerados, para linguagens de programação e até mesmo para banco de dados relacionais ou orientados a objetos O que não é UML A UML não é uma linguagem de programação visual, e sim uma linguagem para modelagem visual. Apesar de oferecer suporte a diversas linguagens de programação, a UML é uma linguagem para construção de artefatos de software que servem para a tomada de decisão quanto à definição de arquitetura, implementação, entre outros. A UML não é um processo de desenvolvimento, mas pode e dever ser aplicado a um. A UML, como uma linguagem de modelagem, pode e deve ser aplicada a um processo de desenvolvimento de software, assim como outros linguagens utilizadas para a construção de artefatos de software. Em um contexto de processos, a UML se propõe a tratar, em diversos domínios, diferentes problemas e em diferentes organizações Onde pode ser utilizada a UML 23

24 A UML pode ser aplicada a qualquer tipo de sistemas de software. Por ser uma linguagem muito abrangente, ela pode ser usada também para modelar processos de trabalhos, projetos de hardware, entre outros Diferenças entre as versões da UML A UML desde seu nascimento vem passando por mudanças em seu conteúdo. Como conseqüência dessas mudanças foram criadas versões mais maduras e completas. A seguir são descritas algumas mudanças (as mais importantes) que ocorreram durante as versões lançadas da UML Versão 1.0 para 1.1 As mudanças mais significativas nessa versão dizem respeito aos diagramas de classes e diagramas de seqüência. Na versão 1.1 as classes pode ser especializadas como tipos ou como classes de implementação. Tipos de Implementação: Uma classe de implementação é realmente uma classe programada no ambiente de software. Uma classe especializada como tipo que pode representar uma abstração do sistema. Podem ser classes que representam apenas o modelo conceitual do sistema ou, ainda, as interfaces do sistema. Portanto, você pode representar em seu modelo de classes de implementação um ou mais tipos; Diagrama de Seqüência: Na versão 1.0 da UML os retornos em diagramas de seqüência eram representados por uma flecha vazada, em vez de uma flecha cheia. Na versão 1.1 os retornos são realizados por meio de uma flexa pontilhada, deixando mais perceptível esse tipo de atividade. Supõe se que essa mudança foi realizada pois a diferença entre uma flecha vazada e uma cheia era muito sutil e de difícil diferenciação; Versão 1.1/1.2 para 1.3 As mudanças realizadas da versão 1.1 para a versão 1.2, foram modificações sutis. Somente na versão 1.3 foram feitas mudanças realmente significativas. Relacionamentos entre casos de uso: Na versão 1.1 da UML havia dois tipos de relacionamentos entre casos de uso: relacionamentos do tipo <<uses>> e <<extends>>. Já na versão 1.3 foram disponibilizados três tipos de relacionamentos: Include: No relacionamento do tipo <<include>> (subtituíndo então <<uses>>) as atividades em comum compartilhadas por alguns casos de uso 24

25 são incluídas em um outro caso de uso público. Por exemplo, em um sistema de análise de crédito pode ser que tanto o processo de aprovação de crédito quanto o processo de reprovação utilizem as atividades de validar a alçada do analista de crédito; Extends: No relacionamento do tipo <<extends>> as atividades de um caso de uso não são obrigatórias são estendidas em um outro caso de uso. Isso significa que um comportamento de caso de uso pode ser desviado apenas em situações predefinidas no caso de uso estendido. Por exemplo, em um processo de análise de crédito, o crédito dos clientes pode ser aprovado automaticamente, sem que tenha de passar por todas as etapas de análise, caso sua renda seja cinco vezes o valor total do financiamento. Esse comportamento de aprovação automática pode mudar todo o comportamento do sistema caso sua condição seja verdadeira; Generalização: No relacionamento de generalização o comportamento comum a mais de um caso de uso em um mesmo domínio é capturado em um supertipo (generalizado). Sendo assim, esses casos de uso agora considerados subtipos (especializados) herdam desse supertipo criando o comportamento comum a eles mesmo; Diagrama de Atividade: Para comportamento condicional, você pode agora usar a atividade de decisão (em forma de losango), para a intercalação ou ramificação de comportamentos. A barra de sincronização é agora referida como separação ou junção. Mas você não poderá mais acrescentar condições arbitrárias às junções. Deve se, então, seguir regras de combinação para assegurar se de que separação e junção combinam. O acionamento duplo não é mais utilizado. Agora você pode utilizar a concorrência dinâmica em um atividade, usando se o asterisco (*); 25

26 3. Modelagem utilizando a UML Esclareceremos agora como é dividida a modelagem de um sistema orientado a objetos e o uso da UML neste contexto. 3.1.Modelagem da arquitetura de sistemas A arquitetura de um sistema representa um conjunto dos artefatos e elementos que formarão o sistema. A arquitetura deve abranger como este será construído, seus elementos estruturais e comportamentais, suas colaborações, entre outras. Construir sistemas de software é uma tarefa que requer a visualização da arquitetura desses sistemas sob várias perspectivas e em diferentes níveis de detalhamento. Todos os envolvidos na construção de sistemas gerentes, analistas, programadores, usuários finais necessitam visualizar a arquitetura de um sistema sob perspectivas diferentes, pois a necessidade de entendimento de cada participante neste processo influenciará seu trabalho futuramente quando o sistema estiver pronto. Portanto, a arquitetura de um sistema deve ser visualizada por meio de cinco visões: Divisão da arquitetura de um sistema Visão Caso de Uso Projeto Descrição Essa visão focaliza os comportamentos de um sistema. A visão deve ser transparente para todos os envolvidos na construção do sistema gerentes, analistas, programados, usuários finais. Diagramas utilizados: Diagrama de casos de uso, interação, atividade e de gráficos de estados. Essa visão focaliza a estrutura (esqueleto) de um sistema. A visão sob essa perspectiva demonstra as classes, colaborações e as interfaces de um 26

27 Visão Processos Implementação Implantação Descrição sistema em construção. Diagramas utilizados: Diagramas de classes, de objetos, interação, atividades e de gráfico de estados. Essa visão focaliza as questões de desempenho, escalabilidade, mecanismos de concorrência e de sincronização. Diagramas utilizados: os mesmos diagramas da visão de projeto. Essa visão focaliza os artefatos físicos para a efetiva montagem do sistema. São abordados componentes e outros arquivos que servem para a montagem do sistema. Diagramas utilizados: Diagrama de componentes, de interação, de atividade e de gráfico de estados. Essa visão focaliza os nós que formam a topologia de hardware em que o sistema será executado. Diagramas utilizados: Diagrama de implantação, de interação, de atividade e de gráfico de estados. 3.2.A importância da modelagem Vamos imaginar um possível situação. Você trabalha para uma grande rede de lojas de departamentos, onde são comercializados diversos produtos como eletrônicos, eletrodomésticos, informática e outros. Esta rede automatizará toda a sua área de concessão de crédito, e você foi designado a conduzir todo o processo de construção de um sistema que atenda as necessidades de negócios da empresa. Esse sistema será encarregado de realizar toda a análise de crédito dos clientes dessas lojas, seguindo uma rigorosa política de crédito estabelecida pela diretoria. Esse sistema deve fornecer informações sobre o crédito do cliente, por meio de Órgãos de Proteção ao Crédito, realizar análises pelo CreditScore, conferir as informações pessoais prestadas pelo cliente, enfim, verificar o enquadramento do perfil desse cliente junto às políticas de concessão de crédito da empresa. A menos que já tenha feito diversos sistemas com as mesmas requisições de negócios, você certamente precisará fazer um planejamento antes de começar a fazer a primeira linha de programação. Nesses caso, você deverá estimar o tempo necessário para que esse sistema seja desenvolvido, bem como qual será o curso do seu desenvolvimento. Será preciso estimar também quais serão os recursos humanos envolvidos nesse processo, bem como o custo de cada recurso, suas responsabilidades, entre outras atividades. 27

28 Dessa forma, para que tudo saia conforme suas estimativas (ou o mais próximo disso) você com certeza necessitará de todos os modelos e esboços desse projeto que demonstrem a complexidade do processo e os riscos possíveis. Além disso, você desejará manter todo o processo documentado, pois em manutenções futuras desses sistema e, caso os desenvolvedores iniciais não estejam mais presentes, você certamente não passará apuros, esperando que se entenda como o processo funciona. Você também desejará que, no próximo sistema que será desenvolvido, se passa reutilizar os processos já criados anteriormente, sem que seja necessário reinventar a roda. Uma das variáveis que farão com que esse processo seja bem sucedido é a utilização da modelagem. Não quer atribuir toda a responsabilidade do sucesso de um sistema, somente pelo fato de uso da modelagem. É evidente que a escolha de bons profissionais com esforço em equipe (e principalmente, o apoio de todos os envolvidos nesse processo) se torna indispensável para que se atinja o objetivo proposto Construindo modelos Imagine a construção de uma nova casa, um novo prédio ou até mesmo um avião, sem que seja construído primeiro os seus respectivos modelos. Seria um erro cuja proporção não poderíamos estimar. Milhões de vidas seriam arriscadas (e certamente perdidas) se não houvesse modelos em que pudéssemos visualizar o que futuramente virá a ser realidade, possibilitando a correção de erros antes que fossem concebidos os produtos finais. Enfim, construimos modelos para compreendermos melhor o sistema que estamos desenvolvendo. Com a modelagem, podemos alcançar: A especificação da estrutura e do comportamento do sistema; A visualização do sistema como ele é ou como desejamos que ele seja; Documentar todas as decisões tomadas; Modelagem orientada a objetos A visão do desenvolvimento de sistemas nos últimos anos, vem adotando uma perspectiva orientada a objetos. Sob esta perspectiva, o principal bloco de construção do sistema é o objeto. Não há dúvidas de que os métodos orientados a objetos têm consolidado seu uso na construção de sistemas de diferentes domínios de problemas, sendo simples ou complexos. 28