ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE LATO SENSU EM ENGENHARIA DE SISTEMAS WALLAS HENRIQUE MENEZES DE SOUZA

Transcrição

1 ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE LATO SENSU EM ENGENHARIA DE SISTEMAS WALLAS HENRIQUE MENEZES DE SOUZA A IMPORTÂNCIA DA MODELAGEM NO DESENVOLVIMENTO DE SISTEMAS VITORIA 2009

2 WALLAS HENRIQUE MENEZES DE SOUZA A IMPORTÂNCIA DA MODELAGEM NO DESENVOLVIMENTO DE SISTEMAS Monografia apresentada à ESAB-Escola Superior Aberta do Brasil, sob orientação da Professora Beatriz Christo Gobbi. VITORIA 2009

3 WALLAS HENRIQUE MENEZES DE SOUZA A IMPORTÂNCIA DA MODELAGEM NO DESENVOLVIMENTO DE SISTEMAS Aprovada em... de... de VITORIA 2009

4 AGRADECIMENTOS À DEUS por ter me modelado a sua imagem e semelhança e por me transmitir a luz da sabedoria, a graça da paciência e o dom da persistência. À minha esposa Cleide M. M. pelo suporte e por me mostrar a importância do amor em tudo o que fazemos. E a minha família por todo apoio fornecido na trajetória da minha vida.

5 Cada um de nós compõe a sua própria história, e cada ser em si, carrega o dom de ser capaz e de ser feliz. (Almir Sater)

6 RESUMO O estudo teve como principal objetivo promover uma análise sobre a importância de se construir modelos no processo de desenvolvimento de sistemas de software, tendo como foco a modelagem de sistemas orientados a objetos. Para ser realizado de forma satisfatória, foi efetuada uma pesquisa bibliográfica apresentando o conceito de modelagem, seus objetivos e princípios fundamentais, bem como as principais razões que justificam a confecção de modelos na construção de sistemas de software. Também foram apresentadas as principais características da UML, linguagem padrão de modelagem para sistemas de software orientados a objetos. Foram obtidas consideráveis informações que permitiram analisar a importância da modelagem. Verificou-se que esta é, sem sombra de dúvidas, uma etapa essencial e primordial para se desenvolver um bom sistema de software. Conclui-se, enfatizando, que para uma melhor elucidação do sistema a ser desenvolvido, é importante que se tenha modelos, permitindo assim uma compreensão maior e integrada por parte dos analistas e programadores das funcionalidades almejadas. Os modelos também configuram como itens na documentação do sistema, mostrando todas as etapas do desenvolvimento do mesmo desde a identificação das necessidades do usuário até a entrega final do produto.

7 LISTA DE FIGURAS Figura 1 Sistema e objetos...25 Figura 2 Exemplo de um modelo de objeto...28 Figura 3 Exemplo de um modelo dinâmico...28 Figura 4 Exemplo de um modelo funcional representado por um DFD...29 Figura 5 Diagramas da UML Figura 6 Diagrama de Classes...41 Figura 7 Diagrama de Estrutura Composta...42 Figura 8 Diagrama de Objetos...42 Figura 9 Diagrama de Componentes...43 Figura 10 Diagrama de Implantação...43 Figura 11 Diagrama de Pacotes...44 Figura 12 Diagrama de Casos de Uso...45 Figura 13 Diagrama de Atividades...45 Figura 14 Diagrama de Máquina de Estados...46 Figura 15 Diagrama de Tempo...46 Figura 16 Diagrama de Seqüência...47 Figura 17 Diagrama de Comunicação...48 Figura 18 Diagrama de Visão Geral...48

8 SUMÁRIO INTRODUÇÃO PALAVRAS CHAVE EXPOSIÇÃO DO ASSUNTO PROBLEMA DE PESQUISA JUSTIFICATIVA OBJETIVO GERAL OBJETIVOS ESPECÍFICOS DELIMITAÇÃO DO TRABALHO METODOLOGIA DE PESQUISA CAPÍTULO 1 O Modelo CONCEITOS SOBRE MODELOS E ABSTRAÇÃO OBJETIVOS DOS MODELOS CAPÍTULO 2 A Modelagem CARACTERÍSTICAS DA MODELAGEM Modelagem Orientada a Objetos A orientação a objetos Conceitos essenciais sobre objetos A Técnica de Modelagem de Objetos PRINCÍPIOS FUNDAMENTAIS CAPITULO 3 Razões da Modelagem PORQUE CONSTRUIR MODELOS CAPITULO 4 A UML HISTÓRICO CARACTERÍSTICAS Visões do Sistema... 38

9 4.2.2 Diagramas da UML Diagramas estruturais Diagramas comportamentais O Futuro da UML CAPITULO 5 FERRAMENTAS DE MODELAGEM FERRAMENTAS PARA MODELAGEM FERRAMENTAS CASE CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS... 56

10 10 INTRODUÇÃO Palavras chave: Informática, Engenharia de Software, Modelagem de Sistemas. EXPOSIÇÃO DO ASSUNTO A área de desenvolvimento de sistemas de software sempre passou por grandes evoluções desde a concepção dos primeiros softwares até os dias de hoje. Nos anos 70, a crise do software provocou muitas dificuldades para os desenvolvedores da época, uma vez que não haviam técnicas adequadas que garantissem a eficiência e eficácia dos softwares construídos. Com a criação da disciplina de Engenharia de Software, a informática viu nascer vários paradigmas e modelos de desenvolvimento que permitiram a evolução da área supracitada de tal sorte que, atualmente existem vários métodos de desenvolvimento tais como: Modelo de Desenvolvimento em Cascata, Modelo Incremental, Paradigma da Orientação a Objeto, as Metodologias de Desenvolvimento Ágil, entre outras. Para o desenvolvedor de software, a principal preocupação deve ser a construção de um produto (software) capaz de satisfazer às necessidades de seus usuários e suas respectivas demandas de negócio a partir de uma verificação apurada e detalhada dos problemas a serem resolvidos aliada aos desejos do usuário sobre a questão. Ou seja, não basta simplesmente modelar e programar o sistema de qualquer jeito. É preciso construir para o usuário uma solução de qualidade e que preferencialmente esteja dentro do prazo acordado entre as partes interessadas.

11 11 Nem sempre as solicitações e requisições oriundas do solicitante do software parecerão lógicas sob a ótica da área de desenvolvimento, mas serão motivadas por questões políticas, negociais ou estruturais no que tange a cultura da empresa envolvida. Considerar todos estes requisitos para o desenvolvimento de um software deve ser o objetivo principal para um desenvolvedor. Por isso, modelar um sistema é uma atividade de primeira grandeza, sem a qual o objetivo principal não será devidamente alcançado. A modelagem é a parte central de todas as atividades que levam à construção e a consequente implantação de um bom sistema de software. PROBLEMA DE PESQUISA No processo de construção e desenvolvimento de sistemas de software, várias são as fases e atividades que são ultrapassadas desde a identificação das necessidades do usuário até a entrega final do produto. Vários modelos são confeccionados durante esse processo. Nesse contexto, qual a importância de se construir modelos no processo de desenvolvimento de sistemas? JUSTIFICATIVA O motivo que provocou a escolha do tema deste trabalho foi o fato da observância da modelagem como atividade essencial para o desenvolvimento de todo e qualquer sistema de software no mundo moderno, a forma como contribui para a qualidade do produto final e a garantia de satisfação do usuário do software. Quando se fala na construção de um software para um determinado grupo de clientes em potencial ou para uma determinada empresa, percebe-se a importância

12 12 da atividade da modelagem, que permite mostrar aos usuários e aos desenvolvedores como o sistema é e como ele deve ser. As literaturas existentes sobre o assunto e consultadas para o desenvolvimento deste trabalho, também colocam a modelagem como gênese do processo de desenvolvimento de software, enfatizando que uma boa modelagem do que será construído afetará positivamente o resultado final do produto entregue. Por fim, o autor deste trabalho também atua profissionalmente com manutenção e desenvolvimento de sistemas empregando a atividade de modelagem no âmbito de suas atividades. OBJETIVO GERAL Promover um estudo sobre a importância da modelagem no desenvolvimento de sistemas de software tendo como foco a modelagem orientada a objetos. OBJETIVOS ESPECÍFICOS - Apresentar o conceito de modelo e seus objetivos no processo de desenvolvimento de sistemas; - Detalhar a etapa de modelagem, citando seus princípios fundamentais pela visão do desenvolvimento orientado a objetos; - Relacionar as principais razões que justificam a utilização de modelos para a construção de sistemas de software;

13 13 - Descrever e explicar as características da UML, padrão para a modelagem de sistemas orientados a objeto. DELIMITAÇÃO DO TRABALHO O tema deste trabalho é a importância da fase de modelagem e a construção de modelos no processo de desenvolvimento de sistemas de software tendo como foco a modelagem de sistemas orientados a objetos. Não se pretende aqui esgotar o assunto sobre modelagem, uma vez que esta é apenas uma fase de todo um processo de desenvolvimento e que também possui os seus desdobramentos. A disciplina de Engenharia de Software engloba outras atividades cada uma com o seu grau de relevância dentro do mesmo processo. Este trabalho será delimitado pela descrição e análise das literaturas encontradas para o tema proposto que especificamente explanam sobre modelagem de sistemas e sobre UML (padrão de modelagem de sistemas orientados a objetos), detalhando conceitos, características e discorrendo sobre a importância da modelagem no contexto de desenvolvimento de softwares. METODOLOGIA DE PESQUISA A metodologia de pesquisa utilizada neste trabalho foi o levantamento de informações e dados na literatura existente para o tema proposto. Foram efetuadas pesquisas bibliográficas em livros técnicos, publicações científicas, informações de sítios da Internet, artigos científicos, monografias, teses etc., que serviram de base para todas as descrições e explanações aqui contidas.

14 14 CAPÍTULO 1 O Modelo 1.1 CONCEITOS SOBRE MODELOS E ABSTRAÇÃO Todas as fontes bibliográficas consultadas para o desenvolvimento deste trabalho, basicamente expressam a mesma definição sobre modelo. Trata-se de um conceito que atualmente, dentro da área de Engenharia de Software, está muito bem alicerçado, difundido e unificado entre, os autores do assunto e as pessoas em geral que atuam profissionalmente nesta área. Visando expressar de forma clara, contundente e satisfatória, o conceito de modelo - que é objeto do presente estudo - os parágrafos a seguir apresentam algumas citações dos autores pesquisados sobre o assunto. Pela definição de Furlan (1998), um modelo é uma abreviação da realidade. Os modelos podem conter planos detalhados bem como planos mais genéricos apresentando uma visão panorâmica do sistema ou parte dele. Um bom modelo inclui detalhes e componentes de grande importância e omite os componentes menores que não necessitam de representação em determinado nível de abstração. Segundo Rumbaugh e Blaha (1994), um modelo nada mais é do que uma abstração de alguma coisa, cujo propósito é permitir que se obtenha conhecimento sobre essa coisa antes de iniciar a sua construção. Cada modelo expressa um aspecto diferente do sistema de software ou programa de computador. Entretanto, o mesmo pode mostrar ou não, referências a outros modelos.

15 15 Para Booch (2000), todo sistema de computador pode ser descrito sob diferentes aspectos, através de modelos diferentes. Cada modelo representa uma abstração semanticamente fechada do sistema. Booch afirma ainda que um modelo pode ser classificado como estrutural, quando enfatiza a organização e as estruturas do sistema ou como comportamental, quando enfatiza a dinâmica e os possíveis comportamentos do sistema. O processo de abstração, citado por Furlan, Rumbaugh e Blaha e Booch, corresponde ao exame seletivo de determinados aspectos de um problema ou contexto qualquer. O objetivo da abstração é isolar as características que sejam importantes para algum propósito e abolir as que não forem. É recomendável que a abstração sempre vise a um propósito, porque este determina o que é e o que não é significativo. Muitas abstrações diferentes da mesma coisa são possíveis, dependendo do objetivo para o qual forem feitas e por quem serão feitas. Ainda falando sobre o conceito de abstração, é possível afirmar que todas as abstrações são incompletas e inexatas. A realidade é como um grande tecido sem costuras. Tudo o que se diz sobre ela, qualquer descrição que se faz dela será apenas um resumo. Entendemos que todas as palavras e linguagens são abstrações, descrições incompletas do mundo real, mas isso não elimina a sua utilidade (Rumbaugh e Blaha, 1994). Conclui-se então que o propósito de uma abstração é impor limites ao universo do qual se dispõe para criar o que precisa ser feito. Na construção de modelos ninguém procura por um modelo que contenha tudo, mas sim o que seja adequado ao propósito almejado. Não existe um único modelo "correto" para todas as situações, apenas modelos adequados e inadequados. Um bom modelo incorpora todos os aspectos fundamentais de um problema a ser trabalhado, resolvido, e omite os demais. O modelo que contém detalhes em

16 16 excesso limita desnecessariamente a escolha das decisões no projeto de desenvolvimento do software e pode ainda, lhe trazer prejuízos uma vez que desvia a atenção dos analistas sobre os problemas reais. Pelas definições apresentadas anteriormente, um modelo representa conceitualmente uma simplificação da realidade, que fornece uma descrição de alguma coisa ou parte dela, por uma perspectiva específica. Áreas como a Engenharia Civil, Aeronáutica e Artes Plásticas, por exemplo, utilizam o mesmo conceito de modelo, usado na Engenharia de Software. Todas elas usam modelos para expressar algo que se quer construir ou simplesmente demonstrar, de uma forma mais aproximada da realidade. Especificamente para a Engenharia de Software, os modelos representam os sistemas de software em sua totalidade ou parcialidade. Na construção dos diversos tipos de sistemas de software existentes atualmente, o desenvolvedor de sistemas faz uso da capacidade de abstração em diferentes níveis. Isso é necessário para que sejam desenvolvidos os modelos que satisfaçam os requisitos do sistema. As especificações são acrescentadas de forma gradual nos modelos visando transformá-los em algo implementado lógica e fisicamente para o computador. 1.2 OBJETIVOS DOS MODELOS Modelos são elaborados para os mais diversos propósitos e objetivos antes de se construir algo. Como objetivos significativos dos modelos para outras áreas não relacionadas com a Engenharia de Software, pode se citar: - a maquete de um prédio, que tem por objetivo mostrar como ficará o prédio depois de pronto;

17 17 - o rascunho de um anúncio no jornal ou versão preliminar de um livro que tem por objetivo servir de base para a versão final; - um esboço a lápis para a composição de uma pintura, que tem por objetivo inspirar um artista na confecção do seu quadro. Em alguns casos, os modelos podem ser usados para testar entidades físicas antes que estas tenham forma pronta. Segundo Rumbaugh e Blaha (1994), modelos em escala de carros e aviões têm sido testados em túneis de vento e tanques de água para aperfeiçoamento da aerodinâmica. Os recentes avanços na área de processamento de dados permitem a simulação de muitas estruturas físicas sem que seja necessário preparar modelos físicos. A simulação não só é mais barata como fornece informações que são muito efêmeras ou inacessíveis para serem medidas a partir de um modelo físico. Os modelos físicos e os modelos em computador são normalmente mais baratos do que a construção de um sistema completo e permitem que os erros sejam corrigidos mais cedo. Na área de Engenharia de Software, os objetivos mais citados pelos autores quanto aos modelos são: - Os modelos ajudam a visualizar o sistema como ele é, ou a definir como ele será. Essas visualizações são importantes para a equipe de desenvolvimento, pois através delas, podem surgir idéias que tragam benefícios à construção do sistema quer seja por introduzir melhoramentos quer seja por excluir aspectos menos significativos, tais como erros de programa e falhas de sistema. Essa regra vale tanto para o sistema que irá ser construído quanto para aquele que já está em uso e passa por um processo de atualização. - Os modelos permitem capturar e comunicar a estrutura e o comportamento do sistema. Aspecto muito importante quando se trabalha no suporte ou no desenvolvimento de um sistema. Entender como ele funciona ou funcionará e como

18 18 responde ou responderá a um determinado evento ou parâmetro fornecido, facilita o trabalho da equipe na correção de um problema ou na criação de uma nova funcionalidade. Além disso, proporcionará economia de tempo e gasto com a análise e manutenção do sistema. - Os modelos proporcionam um guia seguro para a construção do sistema, possibilitando o gerenciamento de riscos. Outro aspecto importantíssimo para a equipe de análise e desenvolvimento de sistemas. É muito mais prático e vantajoso ter em mãos um roteiro que direciona exatamente para o quê deve ser feito minimizando as chances de se construir um recurso inútil ou dispendioso para o sistema. - Os modelos documentam as decisões tomadas pela equipe de análise e desenvolvimento do sistema. O prazo de desenvolvimento e conclusão de um projeto de criação ou aperfeiçoamento de um sistema pode ser longo. Documentar os caminhos decididos e tomados durante o projeto se mostrará uma atividade de suma importância, no futuro quando for necessário realizar algum tipo de consulta às informações do sistema. Modelos são ferramentas valiosas neste quesito.

19 19 CAPÍTULO 2 A Modelagem 2.1 CARACTERÍSTICAS DA MODELAGEM Quando se idealiza a construção de um edifício ou uma casa, por exemplo, o pensamento que surge naturalmente reflete a preocupação do construtor quanto à qualidade e a satisfação do cliente sobre o produto final à ser entregue. Fazer um planejamento detalhado do que será construído é essencial, tendo por finalidade pensar sobre as várias formas de se construir, estimar o tempo e os materiais necessários para a realização do projeto. O desenvolvimento de um sistema de software de qualidade é semelhante a esse processo, pois também reflete o problema abordado como uma questão de arquitetura e de ferramentas. Programas de computador malsucedidos em seu desenvolvimento têm falhas específicas do seu domínio. Mas todos os projetos bem-sucedidos são semelhantes em diversos aspectos. Existem muitos elementos que contribuem para o sucesso de um projeto de software, e com certeza um desses elementos é a utilização da modelagem. A modelagem de sistemas de software é uma técnica da Engenharia de Software aprovada e bem aceita na comunidade de desenvolvimento de sistemas, na qual os modelos são construímos para auxiliar a construção de um novo sistema ou no processo de aperfeiçoamento de um sistema já existente e utilizado. Essa técnica é considerada por muitos autores como a parte central de todas as atividades que levam à implementação de um bom software. Possui grande utilidade porque através

20 20 dela podem ser construídos modelos que descrevam as características ou o comportamento de um sistema e de seus componentes. Na modelagem, os problemas a serem abordados são delimitados e divididos em vários problemas menores, restringindo a atenção da equipe de desenvolvimento para um único aspecto por vez até chegar à solução que contemple o todo. A construção de um sistema simples pode inicialmente influenciar os desenvolvedores a não adotarem a modelagem por não considerá-la importante neste aspecto. Entretanto, a tendência de um sistema funcional é que ele se torne mais complexo ao longo do tempo, necessitando de constantes atualizações e aperfeiçoamentos. Portanto, à medida que o sistema evoluir e não houver nenhum tipo de documentação, como a modelagem, o trabalho será muito maior e ainda com o impacto de se ter um sistema mal-elaborado e repleto de falhas. Mesmo que não se utilize uma modelagem formal para desenvolver um software, sempre é feito algum tipo de modelo, ainda que de uma maneira muito informal. Porém, esses modelos informais não oferecem uma linguagem que pode ser compreendida facilmente por outras pessoas. E, nesse caso, os modelos podem trazer mais malefícios do que benefícios propriamente ditos. Quando os modelos são adequados para o software que está sendo desenvolvido, os problemas são resolvidos mais claramente. Mas, quando se escolhe um modelo errado, ao invés de ajudar, ele pode trazer mais complicações para o problema, causando confusões e desviando a atenção da equipe de desenvolvimento para detalhes que não são importantes naquele momento. Em qualquer situação, os melhores modelos são aqueles que permitem aos desenvolvedores escolher o grau de detalhamento de uma funcionalidade específica. Dependendo do sistema, um modelo que mostra a interação com o

21 21 usuário, de uma forma rápida e simples, pode ser o ideal. Em outros casos, porém, será preciso ter um nível maior de detalhamento, como por exemplo, ao mostrar diversas interfaces necessárias para vários tipos de plataformas de processamento de dados ou quando o sistema se depara com congestionamentos e indisponibilidades em uma rede de computadores. Não raro, é possível observar quantos programas utilizados nas mais diversas empresas de hoje são considerados inadequados e não atendem às necessidades dos usuários. As atuais linguagens de programação visual oferecem grandes facilidades e recursos para o desenvolvimento de sistemas e estão disponíveis para qualquer pessoa que se candidate a usá-las. Todavia, dependendo da quantidade de funcionalidades e quanto maior for o grau de complexidade do sistema, maior será a probabilidade de ocorrência de erros, principalmente por não ter sido utilizada a modelagem no processo de desenvolvimento, uma vez que sem ela, torna-se bastante complicado obter informações sobre as particularidades do software. Um benefício fundamental da modelagem é que ela proporciona um canal de comunicação para membros da equipe de projeto (Reed Jr., 2000). Sem bons modelos, os membros da equipe podem correr o risco de abstrair o conhecimento do sistema por meio de suas próprias opiniões pessoais. No desenvolvimento de um projeto não é recomendável que haja perspectivas individualizadas, por exemplo, de requisitos. Se isso ocorrer, o projeto certamente acabará por não atingir os objetivos pretendidos. Qualquer projeto será beneficiado pelo uso de algum tipo de modelagem. Os modelos auxiliam a equipe a ter uma visão mais detalhada e abrangente sobre o funcionamento do sistema. Esse aspecto agiliza o processo de construção e auxilia na precisão da abordagem efetuada.

22 22 A modelagem de sistemas de software normalmente implica a confecçã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 programas que não são orientados a objeto e que utilizam procedimentos e funções para executar um conjunto de instruções - é através de fluxogramas que são as descrições dos passos necessários para a execução de uma atividade qualquer, enquanto que a modelagem de programas orientados a objeto normalmente usa a linguagem unificada de modelagem - UML. As técnicas de modelagem mais importantes dentro da área de Engenharia de Software são: a análise essencial, a análise estruturada e a análise orientada a objetos, sendo esta última o foco deste trabalho Modelagem Orientada a Objetos A orientação a objetos A orientação a objetos - também conhecida como Programação ou Análise Orientada a Objetos (POO/AOO) - é um paradigma de análise, projeto e programação de sistemas de computador baseado na composição e interação entre diversas unidades de software chamadas de objetos. Este paradigma possui suas origens no campo de estudo da abstração de conceitos do mundo real. Seu objetivo é buscar uma ótica de modelagem sobre esta realidade e seu domínio de problema, em um conjunto de componentes de software que seja o mais fidedigno possível de sua representação deste domínio. A comunicação entre o modelador e os usuários do sistema é facilitada na medida em que a relação mútua entre a simbologia, os conceitos abstratos do mundo real e a ferramenta de modelagem, seja a mais óbvia, natural e exata possível.

23 Conceitos essenciais sobre objetos Para melhor compreensão do paradigma da orientação a objetos, é necessário conhecer os principais conceitos que compõe o referido paradigma, conceitos estes que estão explanados no quadro 1, conforme relacionado a seguir: Conceitos Descrição 1 Classe Representa um conjunto de objetos com características afins. Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos. Exemplo de classe: ser humano. 2 Subclasse Uma nova classe originada de sua classe pai. 3 Objeto É uma instância de uma classe. Um objeto é capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Exemplo de objetos da classe Humanos: João, José, Maria. 4 Atributo São as características que compõe um objeto. Basicamente é a estrutura de dados que vai representar a classe. Exemplos: Um funcionário tem nome, endereço, telefone, CPF e etc. Um carro tem nome, marca, ano, cor e etc. Por sua vez, os atributos possuem valores. Por exemplo, o atributo cor pode conter o valor azul. O conjunto de valores dos atributos de um determinado objeto é chamado de estado. 5 Método Define as habilidades do objeto. Exemplo: Lassie é uma instância da classe Cachorro, portanto tem habilidade para latir, implementada através do método Latido. Um método em uma classe é apenas uma definição. A ação só ocorre quando o método é invocado através do objeto, no caso Lassie. Dentro do programa, a utilização de um método deve afetar apenas um objeto em particular; Todos os cachorros podem latir, entretanto, apenas Lassie pode dar o latido. Normalmente, uma classe possui diversos métodos, tais como FicarSentado, Comer e AplicarMordida, no caso da classe Cachorro. 6 Mensagem Chamada a um objeto para invocar um de seus métodos, ativando um comportamento descrito por

24 24 sua classe. 7 Herança É o mecanismo pelo qual uma classe (subclasse) pode estender outra classe (superclasse), aproveitando seus comportamentos (métodos) e variáveis possíveis (atributos). Exemplo: Mamífero é superclasse de Humano. Ou seja, um Humano é um mamífero. 8 Associação É o mecanismo pelo qual um objeto utiliza os recursos de outro. Ex: Um humano usa um telefone. A tecla "1" é parte de um telefone. 9 Encapsulamento Consiste na separação de aspectos internos e externos de um objeto. Este mecanismo é utilizado amplamente para impedir o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamente apenas os métodos que alteram estes estados. Exemplo: não é necessário conhecer os detalhes dos circuitos de um telefone para utilizá-lo. A carcaça do telefone encapsula esses detalhes, provendo uma interface mais amigável (os botões, o monofone e os sinais de tom). 10 Abstração É a habilidade de se concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software. 11 Polimorfismo É a capacidade de um mesmo método poder ser implementado de diferentes formas, ou mesmo de realizar coisas diferentes dependendo do contexto em que for acionado. Exemplo: o método Calcular da classe OperaçãoMatemática pode implementar uma operação de soma ou de multiplicação dependendo do objeto e da situação em que for invocado. 12 Interface É um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está comprometida a fornecer o comportamento publicado pela interface Pacotes São referências para organização lógica de classes e interfaces. Quadro 1 Conceitos da Orientação a Objetos Fonte: Objetos (2009) Identificar o melhor conjunto de objetos para descrever um sistema de software é a principal meta da orientação a objetos (fig.1). O funcionamento deste sistema se dá

25 25 através do relacionamento e a comunicação entre os objetos envolvidos, sendo esta última realizada por troca de mensagens entre os mesmos. As principais perspectivas da orientação a objetos podem ser resumidas sob os seguintes aspectos: - O bloco principal de construção do software é o objeto; - Métodos e atributos são encapsulados em objetos; - Todos os objetos possuem estado: costuma haver dados a eles associados; - Todos os objetos possuem comportamento: pode ser feito algo com o objeto ou ele poderá fazer algo com outros objetos; - Todos os objetos têm uma identidade: podem receber nomes ou ser diferenciados dos demais objetos de alguma maneira; - O foco do desenvolvimento está na descoberta dos objetos e seus relacionamentos. Figura 1 Sistema e objetos Fonte: Wallas Henrique Menezes de Souza (2009)

26 A técnica de modelagem de objetos A técnica de modelagem de objetos é uma metodologia que combina três tipos de modelos para descrever um sistema. São eles: modelo de objetos, modelo dinâmico e modelo funcional. No conceito de Rumbaugh e Blaha (1994), os três tipos de modelos separam um sistema em visões que podem ser manipuladas e representadas, com uma notação padrão. Esses diferentes modelos não são completamente independentes. Um sistema é mais do que um conjunto de partes independentes (Rumbaugh e Blaha, 1994). Cada modelo pode ser em boa extensão examinado e entendido pelo que representa. Conforme Tonsig (2008), as visões representam os diferentes aspectos do sistema que se está modelando. O mesmo poderá ser construído tendo um número ilimitado de visões; quanto maior for a complexidade do sistema, maior será a quantidade de visões a serem avaliadas, cada uma mostrando aspectos particulares do sistema e propiciando ângulos e níveis de abstração diferentes; assim, um molde completo do sistema poderá ser construído. As visões também podem servir de ligação entre a linguagem de modelagem e o método de desenvolvimento escolhido. Um sistema pode ser analisado sob diferentes perspectivas, de acordo com a visão de quem realizará a análise. Um desenvolvedor de banco de dados tem uma perspectiva direcionada a modelos de relacionamento entre entidades e tabelas, dando ênfase a procedimentos de armazenamento e eventos que os iniciam. Na perspectiva de um profissional da análise estruturada, o foco será nos algoritmos empregados no sistema, com o respectivo fluxo de dados de um processo para outro.

27 27 Se um sistema é construído a partir da perspectiva de um desenvolvedor orientado a objetos, provavelmente a arquitetura será centrada na interação entre classes e como essas classes funcionam em conjunto. Os conceitos baseados em objetos são os que resultam em arquiteturas mais flexíveis porque podem ser aplicados durante todo o ciclo de vida do sistema, desde a análise até o projeto e a implementação. As mesmas classes podem ser conservadas em todas as etapas, sem modificações, embora possam receber detalhes adicionais nas etapas finais. Qualquer sistema deve ser considerado a partir de três aspectos básicos (Tonsig, 2008): - Funcionais: sua estrutura estática e suas interações dinâmicas; - Não-Funcionais: requisitos de tempo, confiabilidade, desenvolvimento etc.; - Organizacionais: organização do trabalho, mapeamento dos módulos, código, distribuição física do hardware etc. Para Rumbaugh e Blaha (1994), é útil modelar um sistema a partir dos três pontos de vista citados anteriormente. As diferenças entre eles são nítidas. Cada um abrange aspectos importantes do sistema, porém todos necessários para uma descrição completa. Um procedimento típico de software incorpora todos esses três aspectos: ele utiliza estruturas de dados (modelo de objetos), sequencia operações no tempo (modelo dinâmico) e transforma valores (modelo funcional). O modelo de objetos (fig.2) descreve a estrutura estática de um sistema, isto é, a estrutura de seus objetos e os relacionamentos existentes entre eles em um determinado instante de tempo. Os atributos e as operações que caracterizam cada classe de objetos também são descritos por neste modelo. Ele é o mais importante dos três modelos porque é o que melhor representa a realidade, sendo mais adaptável às modificações. Os modelos baseados em objetos apresentam uma intuitiva representação gráfica e são úteis para a comunicação com os clientes e para a documentação da estrutura do sistema.

28 28 Figura 2 Exemplo de um modelo de objeto. Fonte: O modelo dinâmico (fig.3) descreve os aspectos de um sistema examinando as modificações ocorridas nos seus objetos e relacionamentos durante um certo período de tempo. Os principais conceitos da modelagem dinâmica são os eventos, que representam os estímulos externos, e os estados, que representam o intervalo entre esses eventos e especificam o contexto em que são interpretados. Figura 3 Exemplo de um modelo dinâmico. Fonte:

29 29 O modelo funcional (fig.4) abrange o que um sistema faz e mostra como os valores de saída de um processamento derivam do processo de entrada, independente da ordem em que os valores são processados. É representado graficamente por meio do diagrama de fluxo de dados (DFD), que mostra o relacionamento funcional entre dados em um sistema, incluindo-se valores de entrada e saída e depósitos internos de dados. Figura 4 Exemplo de um modelo funcional representado por um DFD. Fonte: Cada um dos três modelos evolui durante o ciclo de desenvolvimento do software. Durante a análise, é construído um modelo de domínio da aplicação independentemente de uma ocasional implementação. Durante o projeto, são adicionadas ao modelo construções do domínio da solução. Durante a implementação, são codificadas tanto construções do domínio da aplicação quanto do domínio da solução. A palavra modelo tem duas dimensões - uma visão do sistema (modelo de objetos, dinâmico ou funcional) e uma etapa de desenvolvimento (análise, projeto ou implementação). O significado geralmente independe do contexto.

30 30 Cada modelo descreve um aspecto do sistema e pode conter referências aos outros modelos. O modelo de objetos descreve a estrutura de dados sobre a qual atuam os modelos dinâmico e funcional. As operações do modelo de objetos correspondem a eventos do modelo dinâmico e a funções do modelo funcional. O modelo dinâmico descreve a estrutura de controle de objetos. Ele mostra as decisões que dependem dos valores dos objetos e que provocam ações que modificam esses valores e que invocam as funções descritas no modelo funcional. Este último descreve as funções chamadas pelas operações do modelo de objetos e pelas ações no modelo dinâmico. As funções operam sobe os valores de dados especificados pelo modelo de objetos. O modelo funcional também mostra restrições relativas aos valores dos objetos. Ambiguidades ocasionais sobre qual modelo deve conter uma determinada informação podem ocorrem com certa freqüência. De acordo com Rumbaugh e Blaha (1994), Isso é natural, porque qualquer abstração é apenas uma imitação; alguma coisa inevitavelmente ficará sobre a fronteira. Algumas particularidades de um sistema podem ser mal representadas pelos modelos. Isso também é normal, porque nenhuma abstração pode incluir tudo; a meta é simplificar a descrição sem sobrecarregar o modelo com tantas construções que estas se tornem um peso e não um auxílio. Para aquilo que o modelo não incorporar de forma adequada, a linguagem natural ou uma notação específica para aplicações pode auxiliar na resolução do problema. A modelagem orientada a objetos tem se consolidado porque tem provado seu valor na construção de sistemas de software em diversos domínios de problemas, abrangendo todos os graus de tamanho e complexidade. Os modelos baseados em objetos correspondem mais aproximadamente ao mundo real e são, em consequência, mais adaptáveis às modificações além de implementar algumas das vantagens do paradigma da orientação a objetos como a reutilização de artefatos, a modularidade, a extensibilidade e o forte relacionamento com a realidade.

31 PRINCÍPIOS FUNDAMENTAIS A experiência com o uso da modelagem em todas as disciplinas da engenharia de software sugere quatro princípios básicos, a saber: 1. A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é abordado e como uma solução é definida. 2. Cada modelo poderá ser expresso em diferentes níveis de precisão. 3. Os melhores modelos estão relacionados à realidade. 4. Nenhum modelo único é suficiente. Qualquer sistema não trivial será mais bem investigado por meio de um conjunto de modelos quase independentes. O primeiro princípio pode ser interpretado pela ótica de que os modelos certos iluminam os problemas de desenvolvimentos mais complexos, oferecendo uma visão que provavelmente não seria possível de ser enxergada de outra forma. Em relação a sistemas de software, os modelos escolhidos podem afetar extremamente o olhar da equipe de desenvolvimento em relação ao universo abstraído. Se a realidade a ser modelada for conduzida por um especialista em banco de dados, por exemplo, muito provável que o foco da modelagem será direcionado para o relacionamento entre as entidades e os procedimentos armazenados que expressam o comportamento delas. No entanto se a mesma realidade for trabalhada por um desenvolvedor da orientação a objetos, o sistema terá uma arquitetura centrada em torno de várias classes e padrões de interação que decidirão como essas classes funcionarão em conjunto. Neste caso o importante não é saber qual é a melhor visão e sim que a solução adotada para determinada aplicação ou contexto, seja a mais correta e eficaz. Cada tipo de visão conduz a um tipo diferente de sistema com diferentes benefícios e custos. O segundo princípio diz respeito às necessidades da equipe de desenvolvimento em expressar uma funcionalidade ou um requisito distinto do sistema para o grupo de seus patrocinadores. Para este exemplo uma visão mais genérica do software a ser

32 32 desenvolvido atende satisfatoriamente. Em outros casos, será necessário um nível de aprofundamento maior. Em ambos os cenários, os melhores modelos serão aqueles que permitem a escolha do grau de detalhamento, dependendo de quem está fazendo a visualização e para quem ela está sendo realizada. Todos os observadores desejarão visualizar o sistema em diferentes níveis de precisão e em situações distintas. O terceiro princípio pode ser exemplificado pela representação do modelo físico de um edifício que não atende de maneira semelhante aos materiais reais, obtendo apenas um valor limitado. É melhor possuir modelos que expressem de forma clara sua ligação com a realidade. Quando essa ligação é fraca, será de grande valor saber exatamente o quanto esses modelos divergem do mundo real. Todos os modelos simplificam a realidade. O segredo é garantir que as simplificações não ocultem qualquer detalhe importante. Um bom modelo revela falhas potencialmente fatais para o projeto de desenvolvimento. O quarto princípio é visualizável pela expressão quase independente. Booch (1999) cita para exemplo de compreensão deste princípio, a construção de uma casa. Ela não terá um único conjunto de esboços de projetos capaz de demonstrar todas as particularidades da obra. No mínimo serão necessários vários conjuntos para expressar as instalações elétricas, hidráulicas, plantas baixas etc. Os modelos podem ser construídos e estudados separadamente, mas ainda assim estarão interrelacionados. Para compreender a arquitetura de sistemas orientados a objetos, várias visões complementares e interligadas são necessárias. Uma visão de arquitetura é definida como uma descrição simplificada, uma abstração, de um sistema a partir de uma determinada perspectiva ou ponto de observação, abrangendo interesses particulares, e omitindo os que não são relevantes para essa perspectiva. Cada uma dessas visões conterá aspectos estruturais como também aspectos comportamentais. Em conjunto, elas representam a base do projeto do software.

33 33 CAPÍTULO 3 Razões da Modelagem 3.1 PORQUE CONSTRUIR MODELOS Na atividade de desenvolvimento de um sistema de software deve-se considerar principalmente, os seguintes aspectos: - o sistema deve atender as necessidades dos seus usuários; - o sistema deve ter qualidade duradoura, por meio de uma arquitetura sólida que permita modificações e atualizações de forma rápida e eficiente; - o sistema deve ser construído de forma que a sua manutenção seja feita com o mínimo de desperdício e repetição de trabalho. Na visão de Tonsig (2008), para que esses pontos sejam alcançados, o emprego da modelagem se faz essencial e indispensável. É claro que modelar todo um sistema não é uma atividade simples, uma vez que envolve uma série de fatores passíveis de serem considerados tais como: a organização da empresa envolvida, os processos existentes ou requeridos, os recursos e as informações disponíveis. Entretanto, com uma modelagem bem feita, é bastante provável que se atinja os benefícios subentendidos nos aspectos citados anteriormente. O processo de modelagem não se restringe apenas a sistemas de médio e grande porte. Os softwares razoavelmente modestos também podem desfrutar das vantagens que a modelagem proporciona. Porém, quanto maior e mais complexo for o sistema, maior será a probabilidade de ocorrer falhas e de se construir itens errados (Tonsig, 2008). Detalhes importantes podem ser esquecidos e consequentemente podem impactar negativamente o funcionamento do sistema quando o mesmo estiver implantado. É mais fácil corrigir um modelo incorreto do que refazer todo um sistema. Além disso, construir um modelo tem um custo inegavelmente menor do que construir um software. Erros de projeto identificados

34 34 em modelos trazem menos prejuízos do que aqueles encontrados no próprio software. Existem limites para a inteligência humana de entender complexidades, mais especificamente, absorver todos os detalhes que envolvem uma realidade complexa e os seus relacionamentos existentes incluindo as possíveis situações que possam ocorrer dependendo da combinação dos aspectos envolvidos. Modelos de sistemas complexos são construídos porque é impossível compreendê-los em sua totalidade. Com a ajuda da modelagem, delimita-se o problema limitando o foco a ser abordado a um único item por vez até chegar à solução completa. Dessa forma, o sistema a ser construído será mais bem compreendido. Um melhor gerenciamento da complexidade estudada será alcançado através do uso da modelagem. Dos diversos modelos de um mesmo sistema, cada um pode descrever uma certa perspectiva do mesmo. Assim, detalhes irrelevantes que dificultam o entendimento do todo podem ser ignorados por um instante e permitir que a equipe de desenvolvimento se concentre em funcionalidades específicas de cada modelo separadamente. Na indústria de automóveis, por exemplo, os engenheiros podem analisar os modelos que representa a aerodinâmica, a parte elétrica e o interior do veículo individualmente, e assim compreender melhor a complexidade da construção de um automóvel em sua totalidade. Os modelos usados pelos profissionais permitem um entendimento mais amplo e auxiliam nas tomadas de decisão sobre o andamento do produto. Modelos de sistemas de software usados na Engenharia de Software não são muito diferentes dos modelos usados em outras áreas. Uma boa razão que também justifica o uso da modelagem, é que ela proporciona um bom canal de comunicação para os membros da equipes de projetos (Reed Jr., 2000). O desenvolvimento de um sistema implica em uma grande quantidade de atividades a serem desempenhadas. Os modelos contêm informações sobre essas atividades e por isso mesmo promovem a propagação dessas informações para

35 35 todas as pessoas responsáveis pela construção do sistema. Acrescente-se a isto, o fato de que por conter essas informações, os modelos contribuem de forma considerável no processo de constituição da documentação do sistema. A comunicação com os clientes e usuários igualmente é facilitada com o uso de modelos que demonstram as funcionalidades desejadas. Por fim, cabe relatar que o comportamento futuro do sistema também pode ser analisado e discutido através dos modelos que o descrevem. Neste caso, os modelos representam um ambiente de testes onde as idéias podem ser criadas, debatidas, consolidadas e experimentadas de forma a resolver os problemas abordados na construção do software.

36 36 CAPÍTULO 4 A UML 4.1 HISTÓRICO O Object Management Group (OMG) - organização internacional fundada em 1989 que tem por responsabilidade gerenciar os padrões para aplicações orientadas a objetos aprovou em 1997 a UML como linguagem padrão de modelagem para a orientação a objeto. O termo UML é uma sigla para Unified Modeling Language, que traduzindo para a língua portuguesa ficaria como Linguagem Unificada de Modelagem. Trata-se de uma linguagem visual de modelagem que permite representar os conceitos do paradigma da orientação a objetos através de um conjunto de elementos gráficos, a partir dos quais, pode-se construir diagramas que representam as diversas perspectivas de um sistema. Basicamente, a UML permite que os analistas e desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também descreve significados, isto é, semântica. Ela não é uma metodologia de desenvolvimento, mas auxilia na visualização dos objetos e na comunicação entre eles. É um modo de padronizar as formas de modelagem tendo por objetivos especificar, documentar e estruturar a visualização lógica do desenvolvimento completo de um sistema de software. A UML tem origem na compilação das melhores práticas de engenharia de software que provaram ter sucesso na modelagem de sistemas grandes e complexos. Surgiu dos esforços combinados de Grady Booch, com seu método Booch, James Rumbaugh com a sua Object Modeling Technique - Técnica de Modelagem a Objeto (OMT) -, e Ivar Jacobson com seu método Object Oriented Software Engineering Engenharia de Software Orientada a Objeto (OOSE). Até meados da década de 1990 estas eram as três metodologias de modelagem

37 37 orientada a objetos mais populares entre os profissionais da área de desenvolvimento de software. A associação desses três engenheiros de software ficou mundialmente conhecida pelo termo os três amigos. A UML fornece uma forma padrão para a preparação de planos de arquitetura de projetos de sistemas de software, incluindo aspectos conceituais tais como processos de negócio e funções do sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, projetos de banco de dados e componentes de software reutilizáveis (Booch, Rumbaugh e Jacobson 2000). Pode-se fazer uma analogia da UML com uma caixa de ferramentas. Um construtor usa sua caixa de ferramentas para realizar suas tarefas. Da mesma forma, a UML pode ser vista como uma caixa de ferramentas utilizada pelos desenvolvedores de sistemas para realizar a construção de modelos. Embora a UML reflita claramente as abordagens combinadas dos três metodologistas mencionados anteriormente, ela também inclui as melhores práticas de organizações como a Hewlett Packard (HP), IBM, e Microsoft, bem como outros integrantes da indústria como Shlaer/Mellor, Coad/Yourdon, e Martin/Odell. É a primeira notação a atingir consenso entre os profissionais e acadêmicos da área de Engenharia de Software. Até a pouco tempo, estava na versão 1.5 e, recentemente, foi substituída pela versão 2.0. É provável que se encontre versões mais novas após a criação deste trabalho. A UML é independente tanto de linguagem de programação quanto de processos de desenvolvimento podendo ser utilizada na modelagem de sistemas, independente da linguagem de programação utilizada ou da forma de desenvolvimento adotada. Esse é um fator importante para a utilização da UML, pois diferentes sistemas de software requerem diferentes abordagens de desenvolvimento.

38 CARACTERÍSTICAS Visões do Sistema O desenvolvimento de um sistema de software complexo demanda que seus desenvolvedores tenham a possibilidade de examinar e estudar o problema a partir de diversas perspectivas. Segundo Booch, Rumbaugh e Jacobson (2000), um sistema pode ser descrito por até cinco visões interdependentes, sendo que cada visão (quadro 2) enfatiza detalhes diferentes. A UML fornece vários diagramas que representam essas visões sob diversos aspectos e formas de complementação, facilitando o trabalho de analisar e modelar as funcionalidades do sistema. Entretanto, dependendo das características e do grau de complexidade do sistema, nem todas as visões precisam ser efetivamente utilizadas. Visão Descrição 1 Visão de Casos de Uso Descreve o sistema de um ponto de vista externo como um conjunto de interações entre o sistema e os agentes externos ao sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das outras visões do sistema. 2 Visão de Projeto Enfatiza as características do sistema que dão suporte tanto estrutural quanto comportamental às funcionalidades externamente visíveis do sistema. 3 Visão de Implementação Abrange o gerenciamento das versões do sistema, construídas através do agrupamentos de módulos (componentes) e subsistemas.

39 39 4 Visão de Implantação Corresponde à distribuição física do sistema em seus subsistemas e à conexão entre essas partes. 5 Visão de Processo Enfatiza as características de concorrência (paralelismo), sincronização e desempenho do sistema. Quadro 2 Visões de um sistema pela UML Fonte: ESAB (2007) Diagramas da UML A UML é composta por diversos elementos básicos que representam as diferentes partes de um sistema, como por exemplo: Classe, Interface, Nota, Pacote, Caso de Uso, Atividades, dentre outros. Além disso, a UML permite a criação de elementos próprios através dos estereótipos, valores de etiqueta e restrições, de acordo com Melo (2004). Neste ponto, é importante fazer uma distinção entre um modelo UML e um diagrama (ou conjunto de diagramas) da UML. O último é uma representação gráfica da informação contida no primeiro sendo que este pode existir independentemente. Os diagramas são meios utilizados para a visualização dos blocos de construção da UML, permitindo visualizar o sistema sob diferentes perspectivas através das representações gráficas de um conjunto de elementos. Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada ótica. O enfoque pode ser mais geral, apresentando uma visão externa do sistema - como é o objetivo do Diagrama de Casos de Uso - ou oferecendo uma visão de camada mais profunda do software, apresentando um enfoque mais técnico ou ainda visualizando apenas uma característica do sistema ou um determinado