Módulo 15. Análise e Projeto de Sistemas II. Curso Técnico em Informática - Desenvolvimento de Sistemas

Tamanho: px
Começar a partir da página:

Download "Módulo 15. Análise e Projeto de Sistemas II. Curso Técnico em Informática - Desenvolvimento de Sistemas"

Transcrição

1 Módulo 15 Análise e Projeto de Sistemas II Centro de Educação Profissional de Anápolis CEPA 1 181

2 Título: M15 Análise e Projeto de Sistemas II Copyright Centro de Educação Profissional de Anápolis Autores: Aline Dayany de Lemos Jefferson Santa Cruz Microni Revisão: Aline Dayany de Lemos Jefferson Santa Cruz Microni Luciano Carlos Ribeiro da Silva Diego Menezes Pugas dos Santos Diagramação: Aline Dayany de Lemos Jefferson Santa Cruz Microni Design de Página: Carlos Roberto Pereira Coordenação: Zilda Fernandes da Cruz Rosália Santana Silva Maria Helena da Silva Maria Nazaré Pereira da Neves Eunice Maria Santiago Ana Lucia do Carmo Silva Supervisão Pedagógica: Maria Cristina Alves de Souza Costa Direção: José Teodoro Coelho CEPA Centro de Educação Profissional de Anápolis Rua VP-04, Módulo 3 a 6 DAIA Distrito Agroindustrial de Anápolis Anápolis-GO Tel: (62) Centro de Educação Profissional de Anápolis CEPA

3 Sumário UML Introdução Histórico Conceitos Abstração Classes Objetos Instanciação Encapsulamento Métodos Herança Polimorfismo Diagramas Diagrama de Casos de Uso Atores Casos de Uso Associação (Interação) Diagrama de Atividades Início Fim Atividade Transição de atividade Bifurcação/Junção Decisão Raias ou Swimlanes Sub-Atividade Diagrama de Classes Responsabilidade Componentes Relacionamentos Classe Associativa Classe Abstrata Diagrama de Seqüência Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Mensagens de Retorno Condições ou Mensagens Condicionais Auto-Chamadas ou Auto-Delegações Interação Usuário/Sistema Notações Não Padronizadas Centro de Educação Profissional de Anápolis CEPA 3 381

4 Engenharia de Software Definição de engenharia de Software Princípios de Engenharia de Software Abstração Incrementabilidade Modularidade Rigor e Formalismo Separação de Preocupações (Divisão de Tarefas) Generalização Antecipação de Mudanças Arquitetura Padrões ou Uniformização Ocultamento da Informação Independência Funcional Refinamento Refabricação ou Reutilização Rastreabilidade Gestão de projeto Pessoal Produto Processo Projeto Gestão de Riscos Identificação dos Riscos Projeção dos Riscos Avaliação dos Riscos Gerenciamento e Monitoração dos Riscos Gestão de Qualidade Classificação das Qualidades de Software Qualidades Representativas Apêndice A - Exercícios Casos de Uso Locação de Fitas Controle de Cursos Venda de Passagens Aéreas Clinica Veterinária Escritório de Advocacia Diagrama de Atividade Locação de Fitas Controle de Cursos Venda de Passagens Aéreas Clinica Veterinária Escritório de Advocacia Diagrama de Classes Locação de Fitas Controle de Cursos Venda de Passagens Aéreas Centro de Educação Profissional de Anápolis CEPA

5 Clínica Veterinária Escritório de Advocacia Diagrama de Seqüência Locação de Fitas Controle de Cursos Venda de Passagens Aéreas Clínica Veterinária Escritório de Advocacia Engenharia de Software Gestão de Projetos Gestão de Riscos Gestão da Qualidade Apêndice B - Bibliografia Centro de Educação Profissional de Anápolis CEPA 5 581

6 680 6 Centro de Educação Profissional de Anápolis CEPA

7 Capítulo 01 UML Competência Conhecer os aspectos fundamentais no processo de desenvolvimento de sistema, visando maior qualidade do produto de software, aplicando técnicas de: análise, projeto, implementação e testes. Habilidade Implementar sistemas computacionais, utilizando metodologias que contemple as fases de: análise, projeto, implementação e testes do sistema de software. Centro de Educação Profissional de Anápolis CEPA 7 781

8 880 8 Centro de Educação Profissional de Anápolis CEPA

9 1.1. Introdução A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de orientação a objetos. Essa linguagem tornou-se, nos últimos anos, a linguagem padrão de modelagem de Software adotada internacionalmente pela indústria de Engenharia de Software. Deve ficar bem claro, no entanto, que a UML não é uma linguagem de programação e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros de Software a definir as características do Software, tais como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. Todas essas características são definidas por meio da UML antes do Software começar a ser realmente desenvolvido. Através da UML podemos modelar um sistema utilizando vários diagramas, nos quais podemos destacar dois grandes grupos: Modelagem Estrutural o Diagrama de Classes o Diagrama de Objetos o Diagrama de Componentes o Diagrama de Estrutura Composta o Diagrama de Pacotes o Diagrama de Implantação Modelagem Comportamental (Temporal) o Diagrama de Casos de Uso o Diagrama de Atividades o Diagrama de Transição de Estados o Diagrama de Máquina de Estados o Diagramas de Interação Geral o Diagramas de Interação entre Objetos Diagrama de Seqüência Diagrama de Colaboração Diagrama de Tempo Diagrama de Comunicação 1.2. Histórico UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são conhecidos como "os três amigos". Eles possuem um extenso conhecimento na área de modelagem orientado a objetos já que as três mais conceituadas metodologias de modelagem Orientada a Objetos foram eles que desenvolveram e, a UML é a junção do que havia de melhor nestas três metodologias adicionado novos conceitos e visões da linguagem. Centro de Educação Profissional de Anápolis CEPA 9 981

10 A UML é o resultado da unificação da linguagem de modelagem de objetos de 3 métodos líderes do mercado: Booch, Object Modeling Technique (OMT) e Objected-Oriented Software Engineering (OOSE). Em 1997, a UML v1.1 foi adotada pela OMG (Object Management Group) e desde então tornou-se o padrão da indústria de Software para a modelagem de objetos e componentes. Figura 1 Histórico da UML 1.3. Conceitos Abstração O uso do computador é baseado em abstrações, que nada mais é do que uma representação simplificada da realidade, segundo um ponto de vista específico. Na orientação a objetos o principal mecanismo de abstração é a Classe. Abstração nada mais é do que, a grosso modo, interpretação, ou seja, conseguir enxergar informações que estão subentendidas. Figura 02 Exemplo de Abstração Centro de Educação Profissional de Anápolis CEPA

11 Classes Conceitualmente, uma classe descreve um conjunto de objetos que compartilham características comuns. Uma classe implementa um Tipo Abstrato de Dados, e encapsula esses dados e suas operações. Classe é a definição de um conjunto de objetos que compartilham estruturas e comportamentos comuns, sendo a sua abstração muito importante, dizendo respeito às informações extraídas em um levantamento de requisitos, por exemplo. Assim as classes podem ser entendidas como descrições genéricas ou coletivas de entidades do mundo real. Mantém-se aqui a intenção de aproximar entidades externas de representações internas. Desta forma, a definição das classes de um sistema devera procurar inspiração nas entidades do mundo real. Figura 03 Exemplo de Classe Objetos Um objeto é um elemento que podemos manipular, acompanhar seu comportamento, criar, destruir etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por exemplo, uma máquina, uma organização, ou negócio. Existem objetos que não encontramos no mundo real, mas que podem ser vistos de derivações de estudos da estrutura e comportamento de outros objetos do mundo real. Um objeto é um elemento da classe o Objeto deve pertencer a somente uma classe o O objeto é o elemento que efetivamente armazena as informações de um programa. Objetos trocam mensagens entre si o O funcionamento de um programa OO é caracterizado pela troca de mensagens de objetos criados Centro de Educação Profissional de Anápolis CEPA

12 Figura 04 Exemplos de Objetos Instanciação Instanciação trata-se apenas da criação um objeto a partir de uma classe já definida, isto é, instanciamos um objeto a partir de uma classe. Deve-se ressaltar que Instâncias (Objetos) de uma mesma classe possuem características idênticas, variando os valores que essas características podem assumir. Ex: Todos os objetos de uma classe carro possuem uma característica comum que é cor, mas um pode ter o valor para essa característica igual a Azul e outro Preto. Figura 05 Exemplo de Instanciação Centro de Educação Profissional de Anápolis CEPA

13 Encapsulamento Encapsular significa Proteger dados, ou informações de um objeto, através de métodos, que garantem acesso seguro à informação armazenada nesses objetos. Ocultamento da Informação o O acesso aos dados internos de objetos só pode ocorrer a partir de mensagens. Independência de aplicação o Um método deve acessar informações internas do objeto. Na necessidade de outra informação, somente através de mensagens. Figura 06 Exemplo de Encapsulamento Figura 07 Encapsulamento - Muralha em volta do objeto Centro de Educação Profissional de Anápolis CEPA

14 Métodos Métodos ou comportamentos representam atividades que objetos de uma classe podem executar. É um conjunto de instruções que é executado quando é chamado, por exemplo, um objeto da classe carro pode executar a atividade de transportar pessoas (método). Grande parte da codificação propriamente dita dos sistemas de informação orientados a objetos esta contida nos métodos definidos em suas classes. Figura 08 Exemplo de Método Herança Herança é o reaproveitamento de atributos e métodos, otimizando o tempo de desenvolvimento. É uma das características mais poderosas e importantes da orientação a objetos, porque permite a diminuição de linhas de código. Quando temos herança, a classe que fornece a herança é chamada de SuperClasse, e a que recebe a herança é chamada de SubClasse. Quando uma SubClasse herda os atributos e operações de outra, ela herda todos. O que faz a diferença é a visibilidade, que veremos mais adiante Centro de Educação Profissional de Anápolis CEPA

15 Figura 09 Exemplo de Herança Herança Múltipla Ocorre quando uma SubClasse herda características e métodos de duas ou mais SuperClasses. Figura 10 Exemplo de Herança Múltipla Centro de Educação Profissional de Anápolis CEPA

16 Polimorfismo O conceito de polimorfismo está associado à herança. O polimorfismo trabalha com a redeclaração de métodos herdados por uma classe. Esses métodos, embora semelhantes, diferem de alguma forma da implementação utilizada na SuperClasse, sendo necessário, portanto, reimplementá-los na SubClasse. O conceito polimorfismo é muito semelhante ao conceito de variáveis locais e globais, utilizado pela linguagem de programação C. Ao declararmos uma variável global em um programa escrito na linguagem C, essa variável poderá ser vista e utilizada por qualquer outra função do programa, no entanto se em alguma função declararmos uma variável local com o mesmo nome da variável global, naquela função específica, quando nos referirmos à variável em questão será à variável local e não à global. O mesmo ocorre com os métodos polimórficos, ou seja, supondo existirem diversas SubClasses que herdem um método de uma SuperClasse, se uma delas redeclarar este método, ele só se comportará de maneira diferente nos objetos da classe que o modificou, permanecendo igual à forma como foi implementado na SuperClasse para os objetos de todas as outras classes. Figura 11 Exemplo de Polimorfismo Centro de Educação Profissional de Anápolis CEPA

17 1.4. Diagramas Poderíamos nos perguntar: Porque a UML é composta de tantos diagramas? O objetivo disto é fornecer múltiplas visões do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos, procurando-se assim alcançar a completitude da modelagem, permitindo que cada diagrama complete os outros. Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada ótica, é como se o sistema fosse modelado em camadas, sendo que alguns diagramas enfocam o sistema de forma mais geral, apresentando uma visão mais externa do sistema, como é o objetivo do diagrama de casos de uso, enquanto outros oferecem uma visão de uma camada mais profunda do Software, apresentando um enfoque mais técnico ou ainda visualizando apenas uma característica específica do sistema ou um determinado processo. A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a possibilidade da ocorrência de erros futuros. Figura 12 Diagramas UML Centro de Educação Profissional de Anápolis CEPA

18 Diagrama de Casos de Uso O diagrama de casos de uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os diagramas da UML o mais abstrato e, portanto o mais flexível e informal. O diagrama de casos de uso costuma ser utilizado principalmente no início da modelagem do sistema, principalmente nas etapas de levantamento e análise de requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas. Este diagrama tem por objetivo apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar em como essas funções serão implementadas. O diagrama de casos de uso é de grande auxílio na etapa de análise de requisitos, ajudando a especificar, visualizar e documentar as características, funções e serviços do sistema desejados pelo usuário. O diagrama de casos de uso tenta identificar os tipos de usuários que irão interagir com o sistema, quais os papéis que esses usuários irão assumir e quais funções serão requisitadas por cada usuário específico. Por utilizar uma linguagem informal e apresentar uma visão geral do comportamento do sistema a ser desenvolvido, o diagrama de casos de uso pode e deve ser apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o comportamento do sistema de informação, facilitar o entendimento dos usuários e auxiliar na identificação de possíveis falhas de especificação. É bastante útil e recomendável que um diagrama de casos de uso seja apresentado aos clientes juntamente com um protótipo, que permitirá que um complete o outro Atores Atores são representações de entidades externas, mas que interagem com o sistema durante sua execução. Basicamente, a interação de atores com o sistema se da através de comunicações (troca de mensagens). As entidades externas representadas pelos atores podem ser: o Pessoas: usuário, secretária, aluno, professor, administrador, etc. o Dispositivos: impressora, máquina ou outros equipamentos externo. o Hardware: placa de modem, placa de controle, etc. o Software: sistema de banco de dados, aplicativos, etc. E importante observar que atores representam, na verdade, papéis desempenhados por pessoas, dispositivos ou outros Softwares quando estiverem interagindo com o sistema. Por exemplo, um ator cujo identificador seja Aluno não representa um aluno específico, mas sim um aluno qualquer, ou seja, uma pessoa qualquer que esteja interagindo com o sistema na qualidade de aluno. Desta forma, um ator pode representar um entre vários indivíduos, equipamentos ou Softwares. De forma análoga, uma entidade externa pode ser representada na forma de vários atores. Isto ocorre quando a entidade tem mais de um papel (tipo de participação ou interação) Centro de Educação Profissional de Anápolis CEPA

19 no sistema. Por exemplo, o indivıduo João da Silva poderia ser representado em um sistema na forma do ator Usuário, pois ele interage com o sistema nesta qualidade, e também na forma do ator Administrador, pois ele também interage com o sistema para este outro fim que é a administração do Software. Figura 13 Exemplos de Atores Casos de Uso A descrição dos serviços a serem oferecidos pelo sistema é feita na UML discriminando-se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicação ou uso completo do Software. O conceito de caso de uso não deve ser confundido com o de módulo já que um caso de uso não é um componente do sistema, mas sim um de seus empregos possíveis. Também mas não se deve confundir o conceito de caso de uso com o de função que possui um escopo muito mais limitado, traduzindo frequentemente apenas um recurso ou utilidade do sistema. Um caso de uso é muito mais abrangente, envolvendo todo um conjunto de transações que juntas constituem um serviço completo oferecido pelo sistema. A especificação das funcionalidades de um sistema na forma de casos de uso permite uma visão mais abrangente das aplicações do sistema favorizando um levantamento mais completo e preciso de suas atribuições. Figura 14 Exemplos Caso de Uso Centro de Educação Profissional de Anápolis CEPA

20 Associação (Interação) As associações representam as interações ou relacionamentos entre os atores que fazem parte do diagrama, entre os atores e os casos de uso, ou os relacionamentos entre os casos de uso e outros casos de uso. Os relacionamentos entre os casos de uso recebem nomes especiais como Inclusão, Extensão e Generalização. Uma Associação entre um ator e um caso de uso demonstra que o ator utiliza-se, de alguma maneira, da função do sistema representada pelo caso de uso em questão, seja requisitando a execução daquela função, seja recebendo o resultado produzido por ela a pedido de outro ator. o Relacionamento entre Atores Como os atores são entidades externas, os relacionamentos entre eles serão relações externas ao sistema. Embora estas relações possam ser desprezadas, pois não fazem parte do sistema e nem são de conhecimento do sistema, é possível incluí-las no modelo de casos de uso. De certa forma, estas relações descrevem parte do modelo de negócios da empresa. Figura 15 Exemplos de Relacionamentos entre atores o Relacionamento entre Atores e casos de uso O relacionamento entre um ator e um caso de uso expressa sempre uma comunicação entre eles, pois o ator sendo uma entidade externa não poderia possuir qualquer relacionamento estrutural com o sistema computacional. A notação UML para este tipo de relacionamento é um segmento de reta ligando ator e caso de uso, como ilustrado na figura 15. Em diagramas mais complexos pode-se utilizar cadeias de segmentos de retas para se evitar cruzamentos Centro de Educação Profissional de Anápolis CEPA

21 Como atores podem ter vários propósitos, no que diz respeito a suas interações com o sistema, podem existir mais de um relacionamento de um ator com diferentes casos de usos. De forma análoga, um mesmo caso de uso pode envolver a participação de mais de um ator. A figura 16 ilustra estas situações. O caso de uso Emitir Histórico Escolar envolve a participação de dois atores: Secretaria e Impressora. O ator Secretaria participa em dois casos de uso: Emitir Histórico e Registrar Novo Aluno. Figura 16 Exemplo Relacionamento Ator / Caso de Uso o Relacionamento entre casos de uso e outros casos de uso Ao contrário do relacionamento entre ator e caso de uso, as relações entre casos de uso nunca serão do tipo comunicação. Isto ocorre porque casos de uso são aplicações completas do sistema e, por conseqüência, não existe sentido em fazer-se comunicar dois usos do sistema. Todas as relações entre casos de uso serão sempre estruturais. Existem três tipos de relações entre casos de uso (inclusão, extensão e generalização) conforme descritos a seguir. Inclusão (<<include>>) A associação de inclusão costuma ser utilizada quando existe um serviço, situação ou rotina comum a mais de um caso de uso. Quando isso ocorre à documentação dessa rotina é colocada em um caso de uso específico para que outros casos de uso utilizem-se desse serviço, evitando descrever uma mesma seqüência de passos em vários casos de uso. Os relacionamentos de inclusão indicam obrigatoriedade de execução. Centro de Educação Profissional de Anápolis CEPA

22 Figura 17 Exemplo de Relacionamento de Inclusão Extensão (<<extend>>) Associações de extensão são utilizadas para descrever cenários opcionais de um caso de uso. Eles descrevem cenários que somente ocorrerão em uma situação específica, se uma determinada condição for satisfeita. Representam eventos que não ocorrem sempre, ou seja, são incomuns, não obrigatórios. Figura 18 Exemplo de Relacionamento de extensão Centro de Educação Profissional de Anápolis CEPA

23 Diagrama de Atividades O diagrama de atividades preocupa-se em descrever os passos a serem percorridos para a conclusão de um método ou algoritmo específico e não para um processo completo como é o caso do diagrama de seqüência (como veremos adiante), esse diagrama concentra-se na representação no fluxo de controle de uma atividade. Seus componentes serão descritos e ilustrados a seguir: Início Ponto de entrada de um processo. Pode haver diversos pontos de entradas para o mesmo processo. Figura 19 Exemplo de Início de um processo Fim Ponto de saída (finalização) de um processo. Pode haver diversos pontos de saída para um processo. Figura 20 Exemplo de Fim de Processo Centro de Educação Profissional de Anápolis CEPA

24 Atividade Representação de uma atividade, uma ação a ser realizada. É utilizada quando o usuário faz alguma coisa ou existe resposta do sistema. Figura 21 Exemplo de Atividades Transição de atividade Representa a transição de atividades, também considerado como fluxo. Figura 22 Exemplo de transição de atividade Centro de Educação Profissional de Anápolis CEPA

25 Bifurcação/Junção Em uma caixa de atividade só pode chegar ou sair um fluxo, se houver mais de um fluxo chegando e/ou saindo deve-se utilizar a notação de junção ou bifurcação. A junção é utilizada para quando chega, em uma mesma caixa, mais de uma atividade e a bifurcação é utilizado na distribuição do fluxo para atividades distintas. Figura 23 Exemplo de Bifurcação e Junção Neste caso as duas atividades serão realizadas simultaneamente Decisão Quando há algum tipo de decisão no diagrama de atividade é utilizado um losango. E o fluxo terá no mínimo dois caminhos diferentes a seguir. Centro de Educação Profissional de Anápolis CEPA

26 Figura 24 Exemplo de Decisão Neste caso, somente uma das alternativas será realizado Raias ou Swimlanes Indica a passagem da atividade entre um ator e outro. Pode ser representado na horizontal ou vertical, dependendo do uso. Figura 25 Exemplo do uso de raias Centro de Educação Profissional de Anápolis CEPA

27 Sub-Atividade Uma sub-atividade é um estado em um diagrama de atividades que representa a execução de uma seqüência não-atômica de etapas que possui alguma duração. Pode ser comparado a uma sub-rotina que já foi ou será explorada em outro diagrama de atividades e, portanto, não há a necessidade de explorá-lo no diagrama atual. F i g u r a 2 F Figura 26 - Exemplo de Sub-Atividade Centro de Educação Profissional de Anápolis CEPA

28 Diagrama de Classes O diagrama de classes é, com certeza, o mais importante e mais utilizado diagrama da UML. Seu principal enfoque está em permitir a visualização das classes que irão compor o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as classes do diagrama se relacionam, complementam e transmitem informações entre si. Esse diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-se em como definir a estrutura lógica das mesmas. O diagrama de classe serve ainda como base para a construção da maioria dos outros diagramas da linguagem UML. Basicamente o diagrama de classes é composto por suas classes e pelas associações existentes entre elas, ou seja, os relacionamentos entre as classes. Nesse diagrama a abstração de cada classe com seus atributos e métodos individualmente corresponde à modelagem de vocabulário, onde são definidas as características do sistema. É no diagrama de classes que começamos a sair da parte exclusivamente de negócios e passamos a tornar realidade à automatização do negócio desejado Figura 27 Exemplo de uma Classe Responsabilidade Uma classe sempre deve versar sobre um mesmo assunto. Uma classe encapsula um dado conhecimento sobre algo. Não faz sentido inserirmos, em uma classe que trata de apartamentos, dados sobre a imobiliária ou atrasos de pagamento da hipoteca são assuntos diferentes, portanto, classes diferentes! Uma classe tem responsabilidade por tudo o que lhe diz respeito. Sua responsabilidade é resumida em seus atributos e métodos. Não é de responsabilidade de um proprietário incluir um apartamento, é responsabilidade da própria classe fazer essa inclusão Centro de Educação Profissional de Anápolis CEPA

29 Atributos Componentes Classes costumam definir atributos, também conhecidos como propriedades. Os atributos representam as características de uma classe, ou seja, as peculiaridades que costumam variar de objeto para objeto, como a altura de um OBJETO da classe pessoa ou a cor de um OBJETO da classe carro e que permitem diferenciar um objeto de outro da mesma classe devido a essas variações. Os atributos normalmente possuem duas informações: O Nome que o identifica e o tipo de dado que ele armazena (Ex.: Integer, Float, Caracter, etc.). Essa última informação não é obrigatória, mas é bastante útil e recomendável. Operações (Métodos) Figura 28 Exemplo de Atributos Como já explicado anteriormente os métodos implementam operações a serem executadas pelas classes. Assim temos em sua estrutura: - Nome do Método O nome do método é definido por uma cadeia de caracteres que identificam exclusivamente o método dentro da classe. Sugere-se o emprego unicamente de letras começando-se por uma letra maiúscula e concatenando-se palavras mantendo a primeira letra em maiúsculo. Exemplo: CalcularValor ArmazenarDados - Parâmetros Os parâmetros são variáveis definidas junto aos métodos e que são utilizadas pelos métodos para recebimento de valores no momento da ativação. Os parâmetros podem também ser utilizados para retorno de valores após a execução do método. Cada parâmetro é especificado usando a notação: Centro de Educação Profissional de Anápolis CEPA

30 Nome do Parâmetro:Tipo=Valor Padrão O Nome do Parâmetro é uma cadeia de caracteres que identifica o parâmetro dentro do método. Tipo é um especificador de tipo de dado padrão da linguagem de programação. Valor Padrão é a especificação de uma constante cujo valor será atribuído ao parâmetro se em uma chamada ao método não for especificado um valor para o parâmetro. Exemplo: CalcularValor( val1:int, val2:float=10.0) ArmazenarDados( nome:char[30], salario:float=0.0) - Valor de Retorno O Valor de Retorno indica se o método retorna algum valor ao término de sua execução e qual o tipo de dado do valor retornado. Pode-se utilizar aqui os tipos padrões da linguagem de programação que se pretende utilizar ou novos tipos definidos no projeto (inclusive classes). Exemplo: CalcularValor():int // retorna um valor inteiro ArmazenarDados(nome:char[30]): bool // retorna verdadeiro ou falso F Figura 29 Exemplo de Métodos Centro de Educação Profissional de Anápolis CEPA

31 Visibilidade A visibilidade é utilizada para indicar o nível de acessibilidade de um determinado atributo ou método. Existem basicamente três modos de visibilidade: - A visibilidade pública é representada por um símbolo de ( + ) apresentado na frente da descrição do atributo ou método e significa que o atributo ou método pode ser utilizado por qualquer classe - A visibilidade protegida é representada pelo símbolo de sustenido ( # ) e determina que somente a classe possuidora do atributo ou método ou suas subclasses podem ter acesso ao mesmo. - O atributo ou método privado é representado por um sinal de menos ( - ) e significa que somente a classe possuidora do atributo ou método pode utilizá-lo. Figura 30 Exemplo de Visibilidade Relacionamentos As classes costumam possuir relacionamentos entre si, com o intuito de compartilhar informações e colaborarem umas com as outras para permitir a execução dos diversos processos executados pelo sistema. Associações Uma associação descreve um vínculo que ocorre normalmente entre duas classes, chamado nesse caso de associação binária, mas é perfeitamente válido que uma classe esteja vinculada a si mesmo, caso conhecido como associação unária, ou que uma mesma associação seja compartilhada por várias classes, o que é conhecida como associação ternária ou n-ária, embora esta última seja o tipo de associação mais raro e complexo. Centro de Educação Profissional de Anápolis CEPA

32 Em uma associação, determina-se que as instâncias de uma classe estão de alguma forma, ligadas às instâncias das outras classes envolvidas na associação, podendo haver troca de informações entre elas e compartilhamento de métodos, ou mesmo que uma determinada instância de uma das classes origine uma ou mais instâncias nas outras classes envolvidas nas associações. Uma associação pode ainda identificar algum nível de dependência entre as classes que a compõem. As associações representam o equivalente mais próximo dos relacionamentos utilizados no modelo entidade-relacionamento, ou seja, seu objetivo é definir a maneira como as classes estão unidas e interagem entre si, compartilhando informações. As associações são representadas por retas ligando as classes envolvidas, possuindo ou não setas em suas extremidades para indicar a navegabilidade da associação. Pode-se também definir uma descrição para a associação (Papel) para determinar o vínculo estabelecido entre as classes. o Unária (Reflexiva) (Recursiva) Ocorre quando existe um relacionamento de uma classe para consigo mesma. Figura 31 - Exemplo de associação unária. o Binária É um tipo de associação muito comum, ocorre quando são identificados relacionamentos entre duas classes Centro de Educação Profissional de Anápolis CEPA

33 Figura 32 Exemplo de associação Binária o Ternária (N-ária) São associações que conectam três ou mais classes. São representadas por um losângulo para onde convergem todas as ligações da associação. Figura 33 Exemplo de associação N-ária o Multiplicidade Centro de Educação Profissional de Anápolis CEPA

34 Multiplicidade * * 1..* 3..5 Significado No mínimo Zero e no máximo Um. Indica que os objetos das classes associadas não precisam obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instância da classe se relaciona com as instâncias da outra classe. Um e somente Um. Indica que apenas um objeto da classe se relaciona com os objetos da outra classe. No mínimo Zero e no máximo Muitos. Indica que pode ou não haver instâncias da classe participando do relacionamento. Muitos. Indica que muitos objetos da classe estão envolvidos no relacionamento. No mínimo Um no máximo Muitos. Indica que há pelo menos um objeto envolvido no relacionamento podendo haver muitos envolvidos. No mínimo Três e no máximo Cinco. Indica que existem pelo menos três instâncias envolvidas no relacionamento e que podem ser quatro ou cinco as instâncias envolvidas, não mais que isso. A multiplicidade procura determinar qual das classes envolvidas em uma associação fornece informações para as outras, além de permitir especificar o nível de dependência de uma classe para com as outras classes envolvidas na associação. A multiplicidade é extremamente semelhante ao conceito de cardinalidade utilizado no modelo entidade-relacionamento o Agregação Agregação é um tipo especial de associação onde tenta-se demonstrar que as informações de um objeto(chamado objeto-todo) precisam ser complementadas pelas informações contidas em um ou mais objetos de outra classe (chamado objetoparte). Este tipo de associação tenta demonstrar uma relação todo/parte entre os objetos associados. Objeto-parte não pode ser destruído por um objeto diferente do objeto-todo. O símbolo de agregação difere do de associação por conter um losângulo na extremidade da classe que contém o objeto-todo. A agregação fornece também um canal de comunicação entre o objeto-todo e o objeto-parte. Note que esta comunicação é unidirecional do objeto-todo para o objeto-parte. O objeto-parte não conhece, a princípio, o objeto-todo. Desta forma, ele não pode comunicar-se com o objeto-todo Centro de Educação Profissional de Anápolis CEPA

35 Figura 34 Exemplo de agregação Figura 35 Exemplo da notação de agregação o Composição (Agregação Forte) Representa um vínculo mais forte entre os objetos todo e os objetos parte, demonstra que os objetos parte tem de pertencer exclusivamente a um objeto todo com que se relaciona. Os objetos parte não podem viver quando o objeto todo é destruído. Figura 36 Exemplo de composição Especialização / Generalização (Herança) Este é um tipo especial de relacionamento muito similar à associação de mesmo nome utilizado no Diagrama de Casos de Uso. Seu objetivo é identificar classesmãe, chamadas gerais e classes-filhas, chamadas especializadas. Este tipo de Centro de Educação Profissional de Anápolis CEPA

36 relacionamento permite também demonstrar a ocorrência de métodos polimórficos nas classes especializadas do sistema. Como no Diagrama de Casos de Uso a especialização/generalização ocorre quando existem duas ou mais classes com características muito semelhantes, assim para evitar ter que declarar atributos e/ou métodos idênticos e como uma forma de reaproveitar código, cria-se uma classe geral onde são declarados os atributos e métodos comuns a todas as classes envolvidas no processo e então declaram-se classes especializadas ligadas à classes geral, que herdam todas as suas características podendo possuir atributos e métodos próprios. Além disso, métodos podem ser redeclarados em uma classe especializada, possuindo o mesmo nome, mas comportando-se de forma diferente, não sendo, portanto necessário modificar o código fonte do sistema com relação às chamadas de métodos das classes especializadas, porque o nome do método não mudou apenas foi redeclarado em uma classe especializada e só se comportará de maneira diferente quando for chamado por objetos desta classe. Uma estrutura de generalização/especialização implica herança: um filho herda dados do pai como cor dos olhos e cor da pele. Uma estrutura todo-parte não possui herança: um braço é parte do pai, como suas pernas, mas não há herança nesses casos. Figura 37 Exemplo de generalização/especialização Centro de Educação Profissional de Anápolis CEPA

37 Dependência Identifica certo grau de dependência de uma classe em relação à outra, isto é, sempre que ocorrer uma mudança na classe na qual uma outra classe depende, esta também deverá sofrer uma mudança. O relacionamento de dependência é representado por uma seta tracejada entre duas classes contendo uma seta apontando a classe independente e na outra extremidade está a classe dependente. F Figura 38 Exemplo de Relação de Dependência Classe Associativa Classes associativas são classes produzidas quando da ocorrência de associações que possuem multiplicidade muitos pra muitos. Elas são necessárias nesses casos porque não existe um repositório que possa armazenar informações produzidas pelas associações já que todas as classes envolvidas apresentam multiplicidade muitos e isto obriga que seu atributo chave seja transmitido às outras classes envolvidas e como todas possuem a mesma multiplicidade, nenhuma delas pode receber os atributos das outras, assim é preciso criar uma classe associativa para armazenar os atributos transmitidos pela associação, o que não impede que a classe associativa possua atributos próprios, além dos recebidos. Figura 39 Exemplo de Classe Associativa Centro de Educação Profissional de Anápolis CEPA

38 Classe Abstrata É uma classe que não pode ser instanciada diretamente. Uma classe que contem uma operação abstrata é chamada de classe abstrata. Tal classe não pode criar instâncias porque algumas das operações dela não são implementadas. Classes abstratas têm que ter SubClasses que vão herdar os métodos (concretos) que ela define e vão definir as operações abstratas dela. Classes que têm instâncias podem ser chamadas de concretas. Figura 40 Exemplo de Classe Abstrata Centro de Educação Profissional de Anápolis CEPA

39 Diagrama de Seqüência Este diagrama procura determinar a seqüência de eventos que ocorre em um determinado processo, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparados entre os objetos envolvidos e em que ordem durante um processo específico. Assim, determinar a ordem em que os eventos ocorrem, as mensagens que são enviadas, os métodos que são chamados e como os objetos interagem entre si dentro de um determinado processo é o objetivo principal deste diagrama. O diagrama de seqüência baseia-se no diagrama de casos de uso. No entanto deve se ter em mente que o fato de haver normalmente um único diagrama de caso de uso não significa em absoluto que deva haver um único diagrama de seqüência. Normalmente existem diversos diagramas de seqüência em um projeto, um para cada processo específico do sistema. Um diagrama de seqüência na maioria das vezes se identifica com um caso de uso específico, porque um caso de uso, em geral, refere-se a um processo disparado por um usuário. Assim um diagrama de seqüência também permite documentar um caso de uso. Na verdade, muitas ferramentas CASE permitem gerar um diagrama de seqüência a partir de um caso de uso. Nem sempre um caso de uso gera obrigatoriamente um diagrama de seqüência, como é, muitas vezes, o que ocorre com os casos de uso do tipo <<include>> onde suas etapas são descritas juntamente com o caso de uso que o utiliza, porém nada impede que se defina um diagrama de seqüência exclusivo para o caso de uso do tipo <<include>>. Esse diagrama depende também do diagrama de classes, já que as classes dos objetos declarados no diagrama estão descritas neles, bem como os métodos disparados entre os objetos Atores São exatamente os mesmos descritos no diagrama de casos de uso, ou seja, entidades externas que interagem com o sistema e que solicitam serviços, gerando dessa forma eventos que iniciam processos. Eles são apresentados como bonecos magros, porém contendo uma linha de vida. Atores não são realmente obrigatórios no diagrama de seqüência, mas são utilizados com muita freqüência. Além disso, como a maioria dos diagramas de seqüência, senão todos refletem um aspecto dinâmico de um caso de uso, a utilização dos mesmos atores que interagem com o caso de uso em questão, facilita a compreensão do processo. Centro de Educação Profissional de Anápolis CEPA

40 Figura 41 Exemplo de Ator no Diagrama de Seqüência Objetos Objetos representam as instâncias das classes envolvidas no processo ilustrado pelo diagrama de seqüência. Os objetos são representados por retângulos contendo um texto que identifica primeiramente o nome do objeto, em minúsculo, e depois o nome da classe, com as letras iniciais maiúsculas a qual o objeto pertence. Essas duas informações são separadas por um símbolo de dois pontos ( : ). Os objetos também possuem uma linha de vida, representada por uma linha vertical tracejada que surge abaixo do objeto. Um objeto pode existir desde o início do processo ou ser criado durante o decorrer da execução do mesmo. Se o objeto for criado no inicio do processo o mesmo aparecerá na parte superior do diagrama, se for criado durante a execução ele surgirá na mesma altura em que a mensagem que o criar for chamada Centro de Educação Profissional de Anápolis CEPA

41 Figura 42 Exemplo de Objetos no Diagrama de Seqüência Linha de Vida A Linha de vida representa o tempo em que um objeto existiu durante um processo. As linhas de vida são representadas por linhas finas, verticais tracejadas, partindo do objeto Foco de Controle ou Ativação Indica os períodos em que um determinado objeto está participando ativamente do processo, ou seja, identifica os momentos em que um objeto está executando um ou mais métodos utilizados em um processo específico. Os focos de controle são representados dentro da linha de vida de um objeto, porém enquanto as linhas de vida são representadas por tracejados finos, o foco de controle é representado por uma linha mais grossa. Centro de Educação Profissional de Anápolis CEPA

42 Figura 43 Exemplo de Foco de Controle ou Ativação no Diagrama de Seqüência Mensagens ou Estímulos São utilizadas para demonstrar a ocorrência de eventos, que normalmente forçam a chamada de um método em algum dos objetos envolvidos no processo, ou ainda simplesmente representar a comunicação entre dois atores. o Características É representado por uma reta com seta indicativa do sentido do recebimento da mensagem. É apresentado na horizontal e em ordem seqüencial de cima para baixo (de acordo com o decorrer do tempo), além de possuírem numeração, não obrigatória. Os textos contidos nas mensagens identificam: O método que disparou a mensagem : qual método foi disparado pela mensagem Qualquer uma das partes da mensagem (antes e depois dos dois pontos (:) ) podem ser suprimidas, dependendo da situação Centro de Educação Profissional de Anápolis CEPA

43 Figura 44 Exemplos de Representação e Sintaxe das Mensagens o Significados Chamada de Método (função ou procedimento) É representada por uma reta com uma seta mais grossa (fechada). Indica que um objeto está solicitando a execução de algum método de outro objeto (lembrando que estes métodos devem ser públicos para poderem ser Acessados por outros objetos). Figura 45 Ex. de diferença entre mensagens simples e de ativação de Métodos Criação de Objetos através de Mensagens Quando a mensagem é dirigida a um objeto que já existia, a seta da mensagem atinge a linha de vida do outro objeto, engrossando-a, identificando que o foco de controle está sobre o objeto em questão. Quando a mensagem cria um novo objeto, a seta atinge o retângulo que representa o objeto, indicando que a mensagem representa um método construtor e que o objeto passa a existir somente a partir daquele momento. Centro de Educação Profissional de Anápolis CEPA

44 Figura 46 Exemplo de criação de objetos através de mensagens Destruição de Objetos através de Mensagens Um método destrói ou elimina um objeto não mais necessário, a mensagem atinge a linha de vida do objeto, esse método é chamado de destrutor. Em notações de alguns autores a destruição dar-se-á com interrupção da linha de vida do objeto com um grande X. Figura 47 Exemplo de Destruição de Objetos através de Mensagens Mensagens de Retorno Identifica a resposta a uma mensagem para o objeto ou ator que a chamou. Uma mensagem de retorno pode retornar informações específicas do método chamado ou simplesmente um valor indicando-se o método foi executado com sucesso ou não. São representadas por uma reta tracejada contendo uma seta fina que aponta para o objeto ou ator que recebe o resultado do método chamado Centro de Educação Profissional de Anápolis CEPA

45 Obs.: Se o retorno for de uma validação não gera outro processo. Se o retorno não for validação sempre gerará um novo processo. Figura 48 Exemplo de Mensagens de Retorno Condições ou Mensagens Condicionais Indicam que uma mensagem só poderá ser enviada a um objeto se uma determinada condição for verdadeira. As condições são descritas normalmente entre colchetes na mensagem, mas podem ser representadas por meio de restrições. Associada às condições, pode-se representar o disparo de uma mensagem a vários objetos, através da utilização de um símbolo de asterisco (*), conhecido como símbolo de iteração, devendo definir a quantidade de vezes em que a mensagem é disparada nos objetos de uma determinada classe. Figura 49 Exemplo de Condições Centro de Educação Profissional de Anápolis CEPA

46 Auto-Chamadas ou Auto-Delegações São mensagens que um objeto envia para si mesmo. No caso de auto-chamadas uma mensagem parte do objeto e atinge o próprio objeto. Figura 50 Exemplo de Auto-Chamadas Interação Usuário/Sistema Como já se pode perceber não é possível à manipulação direta dos dados, processos, eventos, métodos pelo ator (usuário do sistema). Por isso utilizamos o conceito de uma entidade especial é denominada <<interface>>(tipo de estereótipo) acompanhado do nome da interface (que pode ser o nome da tela, formulário, página web, etc.), que será o objeto que representará a ligação entre o usuário e os processos propriamente ditos. Podemos considerar a <<interface>> como a tela do sistema e toda a codificação do mesmo, que fará a manipulação dos dados e processos. Figura 51 Exemplo de Interação Usuário/Sistema Centro de Educação Profissional de Anápolis CEPA

47 Notações Não Padronizadas Sobreativação Uma sobreativação é a ativação de um objeto que já estava ativado. Em termos de programa, uma sobreativação representa um empilhamento de função de um mesmo objeto. Um caso simples de sobreativação é a auto-delegação, em particular a chamada de função de um objeto pelo próprio objeto. A função que fez a chamada é empilhada e a função chamada é ativada. Outro exemplo de sobreativação ocorre quando um objeto chama uma função de outro objeto e é empilhado aguardando a conclusão da chamada. O segundo objeto, então, faz uma chamada de função ao primeiro objeto ativando uma função de um objeto que já estava ativado (embora empilhado). Figura 52 Exemplo de Sobreativação e Múltiplos Aninhamentos Múltiplos Aninhamentos Múltiplos aninhamentos ocorrem quando existem múltiplas sobreativações de um objeto. Em termos de programa isto significa múltiplo empilhamento, ou seja, diversas funções de um objeto são chamadas sem que as precedentes tenham concluído sua execução. Estes aninhamentos podem ocorrer em chamadas de função, dentro de blocos condicionais e dentro de repetições. Conforme exemplo da figura 52. Centro de Educação Profissional de Anápolis CEPA

48 Centro de Educação Profissional de Anápolis CEPA

49 Capítulo Engenharia de Software Competência Conhecer as metodologias de gerencia de projetos e organização de equipes de trabalho no desenvolvimento de sistemas. Habilidade Empregar metodologia de trabalho em equipe no desenvolvimento de sistemas computacionais. Centro de Educação Profissional de Anápolis CEPA

50 Centro de Educação Profissional de Anápolis CEPA

51 2.1. Definição de engenharia de Software Os problemas relacionados com o desenvolvimento de Software não são, é claro, resolvidos da noite para o dia, mas reconhecer a existência dos problemas e defini-los da forma mais precisa e eficaz são, sem dúvida, um primeiro passo para a sua solução. Figura 53 - Componentes do Software. Em primeiro lugar, é preciso estar ciente também de que não existe uma abordagem mágica que seja a melhor para a solução destes problemas, mas uma combinação de métodos que sejam abrangentes a todas as etapas do desenvolvimento de um Software. Além disto, é importante e desejável que estes métodos sejam suportados por um conjunto de ferramentas que permita automatizar o desenrolar destas etapas, juntamente com uma definição clara de critérios de qualidade e produtividade de Software. São estes aspectos que caracterizam de maneira mais influente a disciplina de Engenharia de Software. Na literatura, pode-se encontrar diversas definições da Engenharia de Software: "O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um Software que seja confiável e que funcione eficientemente em máquinas reais". A aplicação prática do conhecimento científico para o projeto e a construção de programas computacionais e a documentação necessária à sua operação e manutenção.. Abordagem sistemática para o desenvolvimento, a operação e a manutenção de Software. Centro de Educação Profissional de Anápolis CEPA

52 Conjunto de métodos, técnicas e ferramentas necessárias à produção de Software de qualidade para todas as etapas do ciclo de vida do produto.. Num ponto de vista mais formal, a Engenharia de Software pode ser definida como sendo a aplicação da ciência e da matemática através das quais os equipamentos computacionais são colocados à disposição do homem por meio de programas, procedimentos e documentação associada. De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologia necessária para produzir Software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo. A qualidade de um produto de Software é um parâmetro cuja quantificação não é trivial, apesar dos esforços desenvolvidos nesta direção. Por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados Princípios de Engenharia de Software Nesta seção apresentamos os princípios básicos da engenharia de Software. Estes princípios têm por objetivo o sucesso no desenvolvimento de Software e se preocupam tanto com o processo quanto com o produto final. O processo certo ajudará a produzir o produto certo, mas por outro lado o produto desejado também tem influência na escolha do tipo de processo a ser utilizado. Os princípios apresentados são genéricos o suficiente para serem aplicados através do processo de construção e gerenciamento do software. Princípios, contudo, não são suficientes para conduzir o desenvolvimento de um produto. Na realidade eles são declarações gerais e abstratas que descrevem as propriedades desejadas dos processos de desenvolvimento e dos produtos de software. Porém, para aplicar princípios a engenharia de software deveria estar equipada com métodos apropriados e técnicas específicas para ajudar na incorporação das propriedades desejadas nos processos de desenvolvimento e nos produtos em geral. Primeiramente nós deveríamos saber distinguir métodos e técnicas. Métodos são linhas gerais que regulam previamente uma série de operações que se devem realizar em vista de um resultado determinado. São rigorosos, sistemáticos e disciplinados. Técnicas são maneiras ou habilidades especiais de se executar ou fazer algo. Pode-se dizer que são as habilidades de execução de métodos. A união destes dois pontos forma a metodologia, cujo propósito é promover uma determinada forma para resolver um problema através da pré-seleção dos métodos e técnicas a serem utilizados. Uma metodologia é ainda caracterizada pelo estudo dos métodos em busca de técnicas mais apropriadas e específicas à solução de determinados problemas. As ferramentas por sua vez, são desenvolvidas como mecanismos de apoio à aplicação de métodos, técnicas e metodologias Centro de Educação Profissional de Anápolis CEPA

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

Felipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet)

Felipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet) UML Felipe Denis M. de Oliveira Fonte: Alice e Carlos Rodrigo (Internet) 1 Programação O que é UML? Por quê UML? Benefícios Diagramas Use Case Class State Interaction Sequence Collaboration Activity Physical

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

Modelagem de Casos de Uso (Parte 1)

Modelagem de Casos de Uso (Parte 1) Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes. 1 Diagrama de Classes Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes. Um dos objetivos do diagrama de classes é definir a base para

Leia mais

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com ANÁLISE E PROJETO ORIENTADO A OBJETOS Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Análise Descrição do problema a ser implementado Descrição dos objetos e classes que fazem parte do problema, Descrição

Leia mais

Sumário. Uma visão mais clara da UML

Sumário. Uma visão mais clara da UML Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da

Leia mais

Notas de Aula 04: Casos de uso de um sistema

Notas de Aula 04: Casos de uso de um sistema Notas de Aula 04: Casos de uso de um sistema Objetivos da aula: Aprender os elementos básicos da modelagem por casos de uso Utilizar as associações entre casos de uso, atores e demais artefatos Compreender

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

Guia de utilização da notação BPMN

Guia de utilização da notação BPMN 1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Modelagemde Software Orientadaa Objetos com UML

Modelagemde Software Orientadaa Objetos com UML Modelagemde Software Orientadaa Objetos com UML André Maués Brabo Pereira Departamento de Engenharia Civil Universidade Federal Fluminense Colaborando para a disciplina CIV 2802 Sistemas Gráficos para

Leia mais

UML Aspectos de projetos em Diagramas de classes

UML Aspectos de projetos em Diagramas de classes UML Aspectos de projetos em Diagramas de classes Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o Diagrama de Classes com informações visando uma implementação Orientada

Leia mais

Princípios de Análise e Projeto de Sistemas com UML

Princípios de Análise e Projeto de Sistemas com UML Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 9 Modelagem de estados Todos os adultos um dia foram crianças, mas poucos se lembram disso.

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 17 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 17 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 17 PROFª BRUNO CALEGARO Santa Maria, 19 de Novembro de 2013. Revisão aula anterior Modelagem orientada a objetos com UML Software: Astah Community

Leia mais

Sumário. Capítulo 1 Introdução à UML... 17. Capítulo 2 Orientação a Objetos... 37. Agradecimentos... 6 Sobre o Autor... 6 Prefácio...

Sumário. Capítulo 1 Introdução à UML... 17. Capítulo 2 Orientação a Objetos... 37. Agradecimentos... 6 Sobre o Autor... 6 Prefácio... 7 Agradecimentos... 6 Sobre o Autor... 6 Prefácio... 15 Capítulo 1 Introdução à UML... 17 1.1 Breve Histórico da UML... 17 1.2 Por Que Modelar Software?... 18 1.2.1 Levantamento e Análise de Requisitos...

Leia mais

CAPÍTULO 3 - TIPOS DE DADOS E IDENTIFICADORES

CAPÍTULO 3 - TIPOS DE DADOS E IDENTIFICADORES CAPÍTULO 3 - TIPOS DE DADOS E IDENTIFICADORES 3.1 - IDENTIFICADORES Os objetos que usamos no nosso algoritmo são uma representação simbólica de um valor de dado. Assim, quando executamos a seguinte instrução:

Leia mais

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED UML 01 Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Referências BARBIERI, Carlos. Análise e Programação

Leia mais

2 Engenharia de Software

2 Engenharia de Software 20 2 Engenharia de Software 2.1 Design de Sistemas Orientados a Objetos Os Sistemas Orientados a Objetos não são mais novidade hoje em dia já estando há muitos anos no mercado. A orientação a objetos permite

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Bibliografia UML Guia de consulta rápida Douglas Marcos da Silva Editora: Novatec UML Guia do usuário Grady Booch James Rumbaugh Ivair Jacobson Editora: Campus

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Orientação à Objetos. Aécio Costa

Orientação à Objetos. Aécio Costa Aécio Costa O paradigma da orientação à objetos Paradigma? Um paradigma é uma forma de abordar um problema. No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual

Leia mais

Introdução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com

Introdução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML UML (Unified Modeling Language Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

UML: Diagrama de Casos de Uso, Diagrama de Classes

UML: Diagrama de Casos de Uso, Diagrama de Classes UML: Diagrama de Casos de Uso, Diagrama de Classes Diagrama de Casos de Uso O modelo de casos de uso visa responder a pergunta: Que usos (funcionalidades) o sistema terá? ou Para que aplicações o sistema

Leia mais

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Visão Geral do Sistema Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. A fase de concepção do UP consiste

Leia mais

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos Programação Estruturada e Orientada a Objetos Fundamentos Orientação a Objetos 2013 O que veremos hoje? Introdução aos fundamentos de Orientação a Objetos Transparências baseadas no material do Prof. Jailton

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Orientação a Objetos

Orientação a Objetos 1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

MC536 Bancos de Dados: Teoria e Prática

MC536 Bancos de Dados: Teoria e Prática Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC MC536 Bancos de Dados: Teoria e Prática Aula #3 : MER e MER Estendido Profs. Anderson Rocha e André Santanchè Campinas, 1 de Agosto

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008 Tabela de Símbolos Análise Semântica A Tabela de Símbolos Fabiano Baldo Após a árvore de derivação, a tabela de símbolos é o principal atributo herdado em um compilador. É possível, mas não necessário,

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

O Processo Unificado: Captura de requisitos

O Processo Unificado: Captura de requisitos O Processo Unificado: Captura de requisitos Itana Gimenes Graduação em Informática 2008 Captura de Requisitos Modelagem do negócio: Visão de negócios Modelo de objetos de negócio de negócio Especificação

Leia mais

MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES. lucelia.com@gmail.com

MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES. lucelia.com@gmail.com MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES lucelia.com@gmail.com Externamente ao sistema, os atores visualizam resultados de cálculos, relatórios produzidos, confirmações de requisições solicitadas,

Leia mais

Modelo Entidade-Relacionamento

Modelo Entidade-Relacionamento Modelo Entidade-Relacionamento Banco de Dados I Fases do Projeto jt de BD Enunciado de requisitos entrevista com o usuário do banco de dados para entender e documentar seus requerimentos de dados. Projeto

Leia mais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos MÓDULO 7 Modelo OSI A maioria das redes são organizadas como pilhas ou níveis de camadas, umas sobre as outras, sendo feito com o intuito de reduzir a complexidade do projeto da rede. O objetivo de cada

Leia mais

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena

INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena INF 2125 PROJETO DE SISTEMAS DE SOFTWARE Prof. Carlos J. P. de Lucena Trabalho Experimental Sistema de Gestão Hoteleira 1. Objetivo Este trabalho tem o objetivo de consolidar o conhecimento sobre UML e

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

Algoritmos: Lógica para desenvolvimento de programação de computadores. Autor: José Augusto Manzano. Capítulo 1 Abordagem Contextual

Algoritmos: Lógica para desenvolvimento de programação de computadores. Autor: José Augusto Manzano. Capítulo 1 Abordagem Contextual Algoritmos: Lógica para desenvolvimento de programação de computadores Autor: José Augusto Manzano Capítulo 1 Abordagem Contextual 1.1. Definições Básicas Raciocínio lógico depende de vários fatores para

Leia mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 Exemplo de Diagrama de Caso de Uso Sistema de Locadora de Filmes Sistema de Vídeo Locadora Você foi contratado para desenvolver

Leia mais

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

Mapa Mental de Engenharia de Software - Diagramas UML

Mapa Mental de Engenharia de Software - Diagramas UML Mapa Mental Engenharia Software - Diagramas UML Mapa Mental Engenharia Software Diagramas UML Mapa Mental Engenharia Software Diagramas UML Mapa Mental UML - Diagramas, Fases e Detalhes Resolvi juntar

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.

Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D. UML Diagramas Um diagrama é a apresentação gráfica de um conjunto de elementos, onde os vértices são ITENS e os arcos RELACIONAMENTOS UML 2.0 possui os seguintes diagramas: Diagrama de Classes (Class Diagram)

Leia mais

Uma visão mais clara da UML Sumário

Uma visão mais clara da UML Sumário Uma visão mais clara da UML Sumário 1 Definição de Objeto...2 2 Estereótipos...3 2.1 Classe fronteira (boundary):...3 2.2 Classe de Entidade (entity):...3 2.3 Classe de Controle (control):...4 3 Interação

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

Leia mais

ATRIBUTOS PRIVADOS 6. ENCAPSULAMENTO MÉTODOS PRIVADOS MÉTODOS PRIVADOS

ATRIBUTOS PRIVADOS 6. ENCAPSULAMENTO MÉTODOS PRIVADOS MÉTODOS PRIVADOS ATRIBUTOS PRIVADOS Podemos usar o modificador private, para tornar um atributo privado, obtendo um controle centralizado Definimos métodos para implementar todas as lógicas que utilizam ou modificam o

Leia mais

Questões de Concursos Públicos sobre Orientação a Objetos e UML

Questões de Concursos Públicos sobre Orientação a Objetos e UML Análise Orientada a Objetos Professora Lucélia Oliveira Questões de Concursos Públicos sobre Orientação a Objetos e UML 1. (BNDES) Analise as seguintes afirmações relativas à Programação Orientada a Objetos:

Leia mais

QUESTÃO 2: A respeito do diagrama de caso de uso apresentado, assinale a alternativa correta.

QUESTÃO 2: A respeito do diagrama de caso de uso apresentado, assinale a alternativa correta. CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008/1 4º PERÍODO 7º MÓDULO AVALIAÇÃO A4 DATA 22/10/2009 ENGENHARIA DE SOFTWARE 2009/2 GABARITO COMENTADO QUESTÃO 1: Podemos definir UML

Leia mais

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (Business Process. George Valença gavs@cin.ufpe.br BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de

Leia mais

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5.

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. 1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. Fases do Desenvolvimento de um Sistema em UML 1. Análise

Leia mais

AULA 4 VISÃO BÁSICA DE CLASSES EM PHP

AULA 4 VISÃO BÁSICA DE CLASSES EM PHP AULA 4 VISÃO BÁSICA DE CLASSES EM PHP Antes de mais nada, vamos conhecer alguns conceitos, que serão importantes para o entendimento mais efetivos dos assuntos que trataremos durante a leitura desta apostila.

Leia mais

Prof. Marcelo Henrique dos Santos

Prof. Marcelo Henrique dos Santos ORIENTAÇÃO A OBJETOS COM PROTOTIPAÇÃO CAPÍTULO 02 CONCEITOS FUNDAMENTAIS OBJETIVOS Definiremos alguns conceitos fundamentais de forma a não deixar dúvidas básicas ou interpretações que nos coloquem em

Leia mais

OCOMON PRIMEIROS PASSOS

OCOMON PRIMEIROS PASSOS OCOMON PRIMEIROS PASSOS O OCOMON ainda não possui um arquivo de Help para atender a todas questões relacionadas ao sistema. Esse arquivo serve apenas para dar as principais instruções para que você tenha

Leia mais

Programa do Módulo 2. Fundações do Modelo Objeto

Programa do Módulo 2. Fundações do Modelo Objeto 2.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Processo Unificado (RUP) Fundações do Modelo Objeto 2.2 Programação Orientada a Objetos: é um método de

Leia mais

1. Apresentação. 1.1. Objetivos

1. Apresentação. 1.1. Objetivos 1.1. Objetivos 1. Apresentação Neste capítulo estão descritos os objetivos gerais do livro, os requisitos desejáveis do estudante para que possa utilizá-lo eficientemente, e os recursos necessários em

Leia mais

Engenharia Informática

Engenharia Informática Escola Superior de Ciência e Tecnologia Engenharia Informática Análise de Sistemas Informáticos 3º ano Exame 12 de Julho de 2006 Docentes: José Correia e João Paulo Rodrigues Duração: 90 m; Tolerância:

Leia mais

Dadas a base e a altura de um triangulo, determinar sua área.

Dadas a base e a altura de um triangulo, determinar sua área. Disciplina Lógica de Programação Visual Ana Rita Dutra dos Santos Especialista em Novas Tecnologias aplicadas a Educação Mestranda em Informática aplicada a Educação ana.santos@qi.edu.br Conceitos Preliminares

Leia mais

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com Análise e Projeto de Sistemas de Informação Andrêza Leite andreza.lba@gmail.com Roteiro Sistemas de Informação Ciclo de Desenvolvimento de SI Projeto Análise Estruturada Análise Orientada a Objetos Como

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

Leia mais

Resolução da lista de exercícios de casos de uso

Resolução da lista de exercícios de casos de uso Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se

Leia mais

CASO DE USO. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

CASO DE USO. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com CASO DE USO Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Caso de Uso Descreve o modelo funcional (comportamento) do sistema Técnica de especificaçao de requisitos Especifica um serviço que o sistema

Leia mais

Unidade II MODELAGEM DE PROCESSOS

Unidade II MODELAGEM DE PROCESSOS Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br Introdução O computador como ferramenta indispensável: Faz parte das nossas vidas; Por si só não faz nada de útil; Grande capacidade de resolução

Leia mais

Guia de Especificação de Caso de Uso Metodologia CELEPAR

Guia de Especificação de Caso de Uso Metodologia CELEPAR Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007

Leia mais