Objetivos Profª. Dr. Adriana Soares Pereira [email protected] Fornecer subsídios teórico-práticos necessários ao levantamento, análise e projeto de um sistema computacional. Apresentar os diversos métodos e as técnicas relacionados à análise e ao projeto de sistemas. Realizar a modelagem de um sistema orientado a objetos. 10/08/2011 2 Plano de Ensino UNIDADE 1 - ANÁLISE E PROJETO ORIENTADO A OBJETO 1.1 – Visão Geral da Modelagem de Sistemas. 1.2 - Fundamentos da Orientação a Objetos. 1.3 – Processo de Desenvolvimento de Software. 1.4 - Linguagem de Modelagem Unificada UML (Uified Modeling Language). 1.5 - Diagramas estruturais (diagrama de classes e diagrama de objetos). 1.6 - Diagramas comportamentais (diagrama de casos de uso, diagrama de sequência, diagrama de atividades e diagrama de estados). 1.7 - Uso de ferramentas para modelagem. 1.8 - Modelagem de um Sistema Orientado a Objetos. 10/08/2011 3 Cronograma das Aulas Cronograma de desenvolvimento Data Conteúdo/atividade docente e discente 10/08 Apresentação da disciplina. Fundamentos da Engenharia de Software. Visão geral da modelagem de sistemas. Fundamentos da Orientação a Objetos. 17/08 24/08 31/08 14/09 21/09 28/09 05/10 19/10 26/10 09/11 16/11 23/11 30/11 07/12 14/12 Atividade online. Processo de Desenvolvimento de Software. Trabalho 1. Atividade online. Atividade online. Atividade online. Introdução a UML. Seminário de Apresentação de Trabalhos (Trabalho 2). Seminário de Apresentação de Trabalhos (Trabalho 2). Prova Bimestral. Diagramas Estruturais e Diagramas Comportamentais. Trabalho 3. Utilização de Ferramentas para Modelagem. Aula no laboratório. Utilização de Ferramentas para Modelagem. Aula no laboratório. Modelagem de um sistema orientado a objetos. Aula no laboratório. Prova Bimestral e Apresentação do Trabalho Final. Exame Final 10/08/2011 4 O material de apoio, enunciados de trabalhos e resultados das avaliações serão disponibilizados no site: http://www.cafw.ufsm.br/~adriana/analise.html. Avaliação 1º Bimestre: ◦ Trabalho 1 (peso 1) + ◦ Trabalho 2 (peso 3) + ◦ Prova (peso 6) Avaliação 2º Bimestre: ◦ Trabalho 3 (peso 1) + ◦ Trabalho 4 (peso 6) + ◦ Prova (peso 3) 10/08/2011 5 10/08/2011 6 1 Princípios de Análise e Projeto de Sistemas com UML. A. M. ◦ O funcionamento correto ou incorreto desses sistemas pode ser a diferença entre a vida e a morte Confiabilidade. 1. Rio de Janeiro: Campus. Use a Cabeça! Análise e Projeto Orientado ao Objeto. 2006. arquiteturas paralelas e orientação à objetos ◦ 2000 . I.. Ed. ◦ BOOCH. Utilizando UML e Padrões. Ed. UML Guia do Usuário. multiusuário. 2007. Ed. 2006. Rio de Janeiro: Campus. Modelagem e Projetos Baseados em Objetos com UML 2. Evolução ◦ Década 90 sistemas especialistas. B. G. G. E. WEST. Ed. Programação para internet. BRAHA. 2005. sistemas distribuídos. ◦ Década 80 Lei de Moore avanços na microeletrônica resultaram em um aumento de poder computacional a um custo cada vez menor Redes de computadores 10/08/2011 11 10/08/2011 12 2 . ◦ RUMBAUGH. Ed.. D. WIXOM. 2. Introdução aos Fundamentos de Engenharia de Software Visão Geral da Modelagem de Sistemas Fundamentos da Orientação a Objetos 10/08/2011 7 10/08/2011 8 Crescente importância do software na sociedade ◦ Utilização dos computadores nos mais diversos ramos do conhecimento humano: Aplicações básicas e comerciais Aplicações de tempo real Aplicações científicas e de engenharia Aplicações pessoais e de inteligência artificial.. J. Rio de Janeiro: Campus.. J. Rio de Janeiro: Alta Books. 2. 2006. ◦ MCLAUGHLIN. análise dos requisitos. BIBLIOGRAFIA BÁSICA ◦ BEZERRA. JACOBSON.. etc. 2. 10/08/2011 9 10/08/2011 10 Evolução ◦ Décadas 60 e 70 Hardware com alto custo de processamento e armazenamento de dados Programação estruturada. Ed. B. Rio de Janeiro: LTC. Análise e Projeto de Sistemas. 3. C.. 2. Porto Alegre: Bookman... POLLICE.. ◦ DENNIS. BIBLIOGRAFIA COMPLEMENTAR ◦ LARMAN. 2007. H. RUMBAUGH. BD. (Denis 2006) Software:Subsistema de um sistema computacional. implantação e manutenção) de software. A construção de software não é rápida o suficiente para atender as necessidades do mercado. Atrasos. 10/08/2011 13 10/08/2011 14 Custos elevados. Engenharia: arte das construções. (Denis 2006) Sistema: conjunto de partes que interagem entre si visando um objetivo comum. Começou a ser utilizada na década de 60 Conjunto de problemas recorrentemente enfrentados no processo de desenvolvimento (construção. A habilidade em construir software deixa a desejar em relação ao potencial do hardware. ◦ Além de resistência a mudanças. Software existente é difícil de manutenção. Em informática é o conjunto de software. com base no conhecimento científico e empírico. Dificuldade em manutenção dos softwares devido a maneira artesanal utilizadas no processo: Imprecisão em estimativas de prazos e custos. 1. Baixa produtividade das pessoas e qualidade de software. disciplinada e possível de ser medida para o desenvolvimento. operação e manutenção do software (IEEE . 10/08/2011 15 10/08/2011 16 Aplicação de uma abordagem sistemática. Falhas das pessoas responsáveis pelo desenvolvimento de Software: ◦ Gerentes sem nenhum background em software. ◦ Os desenvolvedores têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software. Ênfase na programação: ◦ O software não se desgasta.Institute of Electrical and Eletronic Engineering). mas se deteriora!!! 2. Gerência de desenvolvimento ineficaz. hardware e recursos humanos. 10/08/2011 17 10/08/2011 18 3 . gestão de projetos.. MaFFEO (1992) a engenharia de software é: "a área interdisciplinar que engloba vertentes tecnológica e gerencial visando a abordar de modo sistemático (modular). ferramentas.. ◦ adequação aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos pertinentes. os processos de construção. conhecimentos dos fatores humanos pelo engenheiro de software e ainda. viável.. SOMMERVILLE (1992) a engenharia de software envolve questões técnicas e não-técnicas. Engenharia de software é metodologia de desenvolvimento e manutenção de sistemas modulares. ". técnicas de projeto e implementação. disciplinada e com abordagem quantitativa para o desenvolvimento. implantação e manutenção de produtos de software com qualidade assegurada por construção segundo cronogramas e custos previamente definidos". procedimentos e princípios a serem utilizados durante o processo de produção de software (percepção do problema. ◦ fundamentação na tecnologia da informação disponível. 10/08/2011 19 ◦ planejamento e gestão de atividades. operação e manutenção de software (IEEE. métodos. produtividade e efetividade em suas atividades e produtos. Reunião de metodologias. tanto a engenharia de software como as técnicas estruturadas são coleções de metodologias de software e ferramentas . planejamento. ◦ efetivação de padrões de qualidade. custos e datas. tais como a especificação do conhecimento. com as seguintes características: ◦ Processo (roteiro) dinâmico. 10/08/2011 20 MARTIN e McCLURE (1991) a engenharia de software é: "o estudo dos princípios e sua aplicação no desenvolvimento e manutenção de sistemas de software . 1990). IEEE: aplicação sistemática.. implantação e manutenção) com o intuito de obter produtos de alta qualidade 10/08/2011 23 10/08/2011 24 4 . 10/08/2011 21 10/08/2011 22 Diversos conceitos ◦ Duas vertentes: Tecnológica e Gerencial ◦ Atenção: Processo de desenvolvimento Administração de processos Ciclo de vida do software ou metodologia de desenvolvimento de software. recursos. integrado e inteligente de soluções tecnológicas. oportuna e personalizada. MÉTODOS: ◦ Proporcionam os detalhes de como fazer para construir o software: Planejamento e estimativa de projeto Análise de requisitos de software Projeto da estrutura de dados e Algoritmo de processamento Codificação. ◦ Quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE. Teste e Manutenção FERRAMENTAS: ◦ Dão suporte automatizado ou semi automatizado aos métodos. Formalidade Abstração Decomposição Generalização Flexibilidade 10/08/2011 27 10/08/2011 28 Paradigmas são modelos de processos que possibilitam ◦ Ao gerente: controle do processo de desenvolvimento de sistemas de software. 10/08/2011 25 10/08/2011 26 PROCEDIMENTOS: ◦ Constituem o elo de ligação entre os métodos e as ferramentas. eficiente. Possibilitam: ◦ Especificação de atividades que devem ser executadas ◦ Ordem de execução das atividades ◦ Ao desenvolvedor: obter a base para produzir. software que satisfação os requisitos pré estabelecidos Objetivo: ◦ Diminuir problemas encontrados no processo de desenvolvimento. ◦ seqüência em que os métodos serão aplicados. de maneira. 10/08/2011 29 10/08/2011 30 5 . Dificuldade em aceitar mudanças em requisitos. Adaptações e atualizações Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe. O cliente deve ter paciência. representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador. ◦ Genéricos ◦ Personalizados 10/08/2011 31 10/08/2011 32 Desenvolvido ou projetado por engenharia. arquitetura. não manufaturado no sentido clássico (não é um processo mecânico). Tradução dos requisitos de software:estrutura de dados. caracterizaçãoTradução das da interface. Coleta de informações para o software. Modelado em função do ciclo da engenharia convencional. Feito sob medida em vez de ser montado a partir de componentes existentes. Utiliza método sistemático e seqüencial em que o resultado de uma fase constitui a entrada de outra. Etapas separadas e distintas para especificação e desenvolvimento. Indicado somente quando os requisitos são bem definidos (pode ser usado em trabalhos acadêmicos). Vários paradigmas já foram propostos: ◦ ◦ ◦ ◦ ◦ Clássico Evolutivo Espiral 4ª Geração Etc. Logo no início é difícil estabelecer explicitamente todos os requisitos. Modelo mais antigo e o mais amplamente usado da engenharia de software . Aspectos lógicos e funcionais internos Correções. Dificuldade em acomodar as mudanças quando o processo está em andamento. Programas (instruções) de computador que executam uma tarefa determinada e sua documentação associada.. No começo dos projetos sempre existe uma incerteza natural. 10/08/2011 35 10/08/2011 36 6 .. 10/08/2011 33 10/08/2011 34 requisitos em nível de sistema – “visão geral do sistema”. Não se desgasta mas se deteriora (obsolescência). Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento. surgiu a necessidade de gerenciar informações de uma forma adequada e eficiente e. UML. Embora o Ciclo de Vida Clássico tenha fragilidades. frameworks. 10/08/2011 40 Um modelo é uma simplificação da realidade que nos ajuda a entender um problema grande e complexo que não pode ser compreendido como um todo. surgiram os denominados sistemas de informações. Phillipe Krutchen. ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software 1. Esse software passou pelo Ciclo de Vida Clássico? 10/08/2011 37 10/08/2011 38 1950/1960: sistemas de software simples ◦ Fluxogramas 1970: expansão do mercado computacional ◦ Programação estruturada 1990: Paradigma orientação à objetos ◦ Análise orientada a objetos (Yourdon e Coad) ◦ Método Booch (Booch) ◦ OMT (Rumbaugh et al) 2000: ◦ Maturidade do paradigma de OO ◦ Padrões de projetos. 7 . desta necessidade. 2000 ◦ Em conseqüência do crescimento da importância da informação. Você conhece algum software comercial? 2. dados. assim como na construção de sistemas habitacionais. mas crescem como um prédio simplesmente devido ao seu Sucesso ◦ Caso não tenha sido considerados questões como arquitetura. também há uma gradação de complexidade. 10/08/2011 47 8 . Um SI é uma combinação de pessoas. ◦ Compreender melhor o sistema que estamos elaborando (simplificação e reaproveitamento) • Uma analogia. processos e ferramentas a “casa de cachorro ampliada” sucumbirá. processos. Característica intrínseca do desenvolvimento de sistemas de software: complexidade.. Compreende os módulos funcionais computadorizados que interagem entre si para proporcionar a automatização de diversas tarefas. ◦ Vantagens do ponto de vista competitivo. A construção desses sistemas necessita de um planejamento inicial. Definição de Modelagem de Sistemas A modelagem é parte central de todas as atividades que levam à implantação de um bom software Construímos modelos para: ◦ Comunicar a estrutura e o comportamento desejado do sistema. interfaces.. Casa de canhorro Casa Arranha-Ceús Aumento da complexidade Muitos projetos nascem como uma casa de cachorro “simples”. ◦ Visualizar e controlar a arquitetura do sistema. Na construção de sistemas de software. Objetivo principal e final da construção de um SI: adição de valor. redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização com relação às informações. caso não haja qualquer modelagem. ◦ Correção de erros encontrados em modelos é mais barata que correções no sistema propriamente dito. ◦ Softwares inadequados Quanto mais complexo for o sistema. Modelos proporcionam um guia para a construção. Redução dos custos no desenvolvimento. Projetos de software mal sucedidos falham em relação a aspectos únicos e específicos de cada projeto Todos os projetos bem sucedidos são semelhantes em diversos aspectos ◦ Modelagem: uma representação idealizada de um sistema a ser construído diagramas A maioria dos softwares comerciais são desenvolvidos sem nenhum tipo de modelagem. Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos. 10/08/2011 51 10/08/2011 52 Visualizar o sistema como ele é e como desejamos que seja. De uma perspectiva mais ampla. Redução de tempo e custos de desenvolvimento. maior será a probabilidade de ocorrência de erros ou de construção de itens errados. um modelo pode ser visto como uma representação idealizada de um sistema a ser construído. isto deve-se à produtividade oferecida pela linguagens de programação atuais. Predição do comportamento futuro do sistema. Gerenciamento da complexidade inerente ao desenvolvimento de software. 10/08/2011 53 10/08/2011 54 9 . Comunicação entre as pessoas envolvidas. Modelos documentam decisões tomadas. Ou seja: ◦ Limitações do ser humano em lidar com a complexidade (diversos modelos para um mesmo sistema) ◦ O comportamento do sistema pode ser analisado através de seus modelos ◦ Modelos servem de “laboratórios” para a construção do sistema. Modelos permitem especificar a estrutura e o comportamento de um sistema. estado e comportamento) Forma de solucionar problemas do cotidiano (mais próxima do homem) 10/08/2011 55 10/08/2011 56 O mapa rodoviário de uma cidade que mostra as rodovias e prédios e que esconde a cor dos prédios.pode ser considerado um modelo? Por quê? Discuta as características desse mapa com o princípio da abstração: Exemplifique um modelo da realidade: 10/08/2011 57 10/08/2011 58 O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos.a escolha de um modelo influenciará na definição e solução do problema. 3º . É através da interação entre objetos que uma tarefa computacional é realizada.os melhores modelos estão relacionados à realidade. 1º .nenhum modelo único é suficiente ( um sistema é composto por vários modelos) Existem várias maneiras de definir um modelo. 4º . ◦ Paradigma Estruturado Elementos: dados e processos Desenvolvimento: algoritmos Dificuldade de manutenção à medida que os sistemas crescem ◦ Paradigma Orientada à Objetos Elemento: objeto (possuem identidade. 10/08/2011 59 10/08/2011 60 10 .cada modelo deverá ser expresso em diferentes níveis de precisão. Cada objeto é responsável por realizar tarefas específicas. 2º . Uma mensagem é uma requisição enviada de um objeto a outro para que este último realize alguma operação. EX: bola. Independentemente da origem do estímulo. diz-se que o objeto em questão está recebendo uma mensagem. Objetos de um sistema trocam mensagens Objeto Objeto Objeto Objeto Objeto 10/08/2011 65 10/08/2011 66 11 . Seres humanos costumam agrupar objetos. 3. deve haver um estímulo enviado a este objeto. 5. Classe Carro Classe Cachorro 10/08/2011 63 10/08/2011 64 Para que um objeto realize alguma tarefa. ou seja. 10/08/2011 61 10/08/2011 62 O mundo real é formado de coisas. Na terminologia de orientação a objetos. é a definição de como um objeto se comportará quando este for criado ou instanciado. 1. Qualquer coisa é um objeto. Cada objeto pertence a uma determinada 4. Objetos realizam tarefas através da requisição de serviços a outros objetos. classe. 2. Diz-se que um objeto é uma instância de uma classe. Classe é uma abstração das características relevantes de um grupo de coisas do mundo real. A classe é um repositório para comportamento associado ao objeto. quando ele ocorre. Classes são organizadas em hierarquias. Uma classe é um molde para objetos. estas coisas do mundo real são denominadas objetos. Uma classe agrupa objetos similares. Maior abstração Menor abstração 10/08/2011 69 10/08/2011 70 É a habilidade de objetos de classes diferentes responderem a mesma mensagem de diferentes maneiras. ◦ Cada nível de uma hierarquia pode ser visto como um nível de abstração. Ex: relacionamento ente pai e filho 10/08/2011 71 10/08/2011 72 12 . classes semelhantes são agrupadas em hierarquias. A herança facilita o compartilhamento de comportamento entre classes semelhantes. ◦ Cada classe em um nível da hierarquia herda as características das classes nos níveis acima. a única coisa que o objeto precisa saber para pedir a colaboração de outro objeto é conhecer a sua interface. Herança: Ex: veículo e carro. Objetos possuem comportamento. Interface (“cartão de visitas de um objeto”) Através do encapsulamento. Na herança. Agregação: Ex: carro e motor.uma”. Geralmente conhecido como relação “é. Um objeto (requisitante) que precise da colaboração de outro objeto (requisitado) para realizar alguma tarefa não precisa conhecer a maneira como serão executadas suas solicitações no objeto requisitado. Geralmente conhecido como relação “parte de”. O encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto. As diferenças ou variações de uma classe em particular podem ser organizadas de forma mais clara. ele (requisitante) apenas precisa conhecer quais as tarefas que podem ser realizadas por este objeto. O termo comportamento diz respeito a que operações são realizadas por um objeto e também de que modo estas operações são executadas. Associação: um objeto de alguma forma está associado ao outro. 10/08/2011 67 10/08/2011 68 A herança pode ser vista como um nível de abstração acima da encontrada entre classes e objetos. panfletos. vídeos. Desenhe um modelo de objeto que identifique as semelhanças (herança) entre carros e veículos 2. revistas. 3. fita e jornais. CDs de música. 10/08/2011 73 10/08/2011 74 Atividade online! 10/08/2011 75 13 . Desenhe um modelo de objetos que identifique as semelhanças no sistema de um biblioteca que manipule livros. 1. Encontre as funções no problema da biblioteca que possam ser comuns a todos os itens (polimorfismo) e funções que terão que ser especializadas para cada classe derivada.