Parte 1 do material sobre UML, contendo:
- introdução a Orientação a Objetos
- visão geral do processo de software OO
- histórico da UML
- diagramas de casos de uso
- diagramas de classes
O documento discute conceitos fundamentais de sistemas de informação, incluindo:
1) A natureza dos sistemas e definições gerais de sistemas;
2) Componentes básicos de sistemas como entrada, saída, processamento e feedback;
3) Princípios gerais de sistemas como especialização, tamanho e inter-relacionamento.
O documento discute a arquitetura de software, definindo-a como a estrutura de um sistema de software, incluindo os componentes, propriedades e relacionamentos. Também aborda linguagens para descrever arquitetura, visões e padrões de arquitetura.
Este documento fornece um resumo sobre projeto de software, abordando tópicos como:
1) Definição de projeto de software e sua importância no ciclo de vida do desenvolvimento;
2) Processo de projeto, incluindo modelos estruturado e orientado a objetos;
3) Conceitos fundamentais como abstração, modularidade e padrões;
4) Técnicas como refatoração e estruturação em camadas e MVC.
O documento discute conceitos de projeto e arquitetura de software, incluindo padrões de arquitetura como camadas, MVC e cliente-servidor. Referências adicionais são fornecidas para aprofundar o conhecimento sobre o assunto.
O documento discute as etapas do desenvolvimento de software, incluindo: 1) Reunião com o cliente para entender os requisitos; 2) Especificação formal dos requisitos; 3) Desenvolvimento do código e teste. O processo é guiado por metodologias como Scrum e Kanban através de reuniões de planejamento.
No ensino de arquitetura de computadores, um dos principais desafios é fazer com que os alunos compreendam com mais facilidade o funcionamento de um processador. Para auxiliar a esta tarefa, são utilizadas aplicações que simulam tais arquiteturas. A proposta do presente trabalho é desenvolver uma aplicação, disponibilizada na web, que simule visualmente as instruções de uma arquitetura didática e implementável. É possível visualizar a simulação de tais instruções com ou sem pipeline, o que facilita a compreensão das mesmas e do funcionamento de um processador enquanto as executam.
A virtualização permite simular plataformas de hardware, sistemas operacionais e recursos de rede em uma única máquina. Isso cria máquinas virtuais que podem executar sistemas operacionais e aplicativos como se fossem computadores reais. A virtualização oferece vantagens como economia de hardware, teste e desenvolvimento de software, e consolidação de servidores.
O documento discute conceitos fundamentais de sistemas de informação, incluindo:
1) A natureza dos sistemas e definições gerais de sistemas;
2) Componentes básicos de sistemas como entrada, saída, processamento e feedback;
3) Princípios gerais de sistemas como especialização, tamanho e inter-relacionamento.
O documento discute a arquitetura de software, definindo-a como a estrutura de um sistema de software, incluindo os componentes, propriedades e relacionamentos. Também aborda linguagens para descrever arquitetura, visões e padrões de arquitetura.
Este documento fornece um resumo sobre projeto de software, abordando tópicos como:
1) Definição de projeto de software e sua importância no ciclo de vida do desenvolvimento;
2) Processo de projeto, incluindo modelos estruturado e orientado a objetos;
3) Conceitos fundamentais como abstração, modularidade e padrões;
4) Técnicas como refatoração e estruturação em camadas e MVC.
O documento discute conceitos de projeto e arquitetura de software, incluindo padrões de arquitetura como camadas, MVC e cliente-servidor. Referências adicionais são fornecidas para aprofundar o conhecimento sobre o assunto.
O documento discute as etapas do desenvolvimento de software, incluindo: 1) Reunião com o cliente para entender os requisitos; 2) Especificação formal dos requisitos; 3) Desenvolvimento do código e teste. O processo é guiado por metodologias como Scrum e Kanban através de reuniões de planejamento.
No ensino de arquitetura de computadores, um dos principais desafios é fazer com que os alunos compreendam com mais facilidade o funcionamento de um processador. Para auxiliar a esta tarefa, são utilizadas aplicações que simulam tais arquiteturas. A proposta do presente trabalho é desenvolver uma aplicação, disponibilizada na web, que simule visualmente as instruções de uma arquitetura didática e implementável. É possível visualizar a simulação de tais instruções com ou sem pipeline, o que facilita a compreensão das mesmas e do funcionamento de um processador enquanto as executam.
A virtualização permite simular plataformas de hardware, sistemas operacionais e recursos de rede em uma única máquina. Isso cria máquinas virtuais que podem executar sistemas operacionais e aplicativos como se fossem computadores reais. A virtualização oferece vantagens como economia de hardware, teste e desenvolvimento de software, e consolidação de servidores.
O documento explica o que é um diagrama de casos de uso, seus principais componentes e objetivos. Ele descreve como os diagramas de casos de uso mapeiam requisitos funcionais e servem como base para outros diagramas da UML, representando as interações entre atores e casos de uso de uma maneira abstrata e flexível.
O documento descreve uma aula prática sobre sistemas operacionais usando o simulador SOsim. A aula inclui seis práticas simulando processos, tipos de processos, PCB, estatísticas, log de execução e suspensão/eliminação de processos. O objetivo é apresentar conceitos como escalonamento de processos, CPU-bound vs I/O-bound e contexto de software e hardware.
Conceitos e princípios dos métodos ágeis, com foco no Scrum. Aborda também técnicas, cerimônias e ferramentas da gestão ágil. Apresentado para diversas áreas do Senado Federal, com o intuito de difundir as práticas para toda a organização.
1) A análise de requisitos é fundamental para obter um software de alta qualidade e envolve descobrir e refinar os requisitos através da comunicação entre cliente e desenvolvedor.
2) Os principais passos da análise incluem modelar o domínio da informação, desenvolver modelos do sistema, particionar o problema e especificar requisitos funcionais e não funcionais.
3) Uma especificação de requisitos efetiva separa funcionalidade de implementação, modela o sistema e seu ambiente, e é revisada para garantir completude e
O documento descreve modelos tradicionais e ágeis de engenharia de software, incluindo Cascata, Espiral, Processo Unificado, Crystal, Scrum e Programação Extrema. Os modelos tradicionais têm dificuldade em lidar com mudanças, enquanto os modelos ágeis enfatizam adaptação, colaboração com o cliente e entregas frequentes.
O documento explica os principais elementos de diagramas de casos de uso, incluindo atores, casos de uso, relacionamentos e cenários. Casos de uso representam funções do sistema, enquanto atores representam entidades externas. Há diferentes tipos de relacionamentos que podem existir entre casos de uso.
O documento apresenta um diagrama de classes para modelar um sistema de matrícula universitária. Ele descreve as classes Professor, Coordenador, Estudante, Turma, Disciplina, Formulário de Matrícula e Analisador de Matrícula e seus relacionamentos.
O documento discute conceitos de programação, como programas, gráficos de Gantt e programação para frente e para trás. A programação é o planejamento de volumes e horários em um ambiente. Gráficos de Gantt representam o tempo em barras para demonstrar quando tarefas começam e terminam. Sistemas de programação podem ser empurrados ou puxados, com diferentes vantagens e consequências.
O documento discute os conceitos fundamentais de arquitetura de software, incluindo: (1) arquitetura de software é o conjunto de estruturas que compõem um sistema, incluindo módulos, componentes e conectores, e alocação; (2) módulos dividem o sistema em unidades de implementação com responsabilidades específicas; (3) componentes e conectores representam elementos de software e suas interações em tempo de execução.
O documento discute os conceitos fundamentais de modelagem de dados, incluindo:
1) Entidades, atributos e chaves primárias definem as tabelas e campos do banco de dados.
2) Relacionamentos entre entidades representam como os dados serão ligados entre tabelas.
3) A normalização organiza os dados em tabelas separadas para evitar duplicação e inconsistências.
O documento descreve os componentes e construção de diagramas de sequência no UML. Especificamente, ele explica que diagramas de sequência ilustram a interação entre objetos através da troca de mensagens, e incluem atores, objetos, mensagens, linhas de vida e foco no controle para representar a criação e destruição de objetos.
O documento introduz conceitos básicos de engenharia de software, incluindo: (1) a definição de software e a crise histórica no desenvolvimento de software, (2) a introdução da engenharia de software para lidar com os desafios por meio de modelos de processo e gerenciamento de projetos, e (3) os principais modelos de processo e gerenciamento de projetos de software.
O documento apresenta os conceitos de diagramas de casos de uso. Explica que eles descrevem as interações entre atores e o sistema, sem detalhar como o sistema funciona internamente. Detalha os componentes de um diagrama de casos de uso, incluindo atores, casos de uso e associações, e fornece exemplos de cada um.
O documento discute métodos ágeis de desenvolvimento de software. Apresenta os problemas do desenvolvimento tradicional e descreve princípios como o Manifesto Ágil. Detalha práticas como XP e Scrum e fornece links para recursos adicionais sobre os tópicos discutidos.
O documento discute o que é lógica. A lógica procura compreender como pensamos de forma técnica e ensina a usar as leis do pensamento corretamente. A lógica é considerada uma ciência que organiza o pensamento corretamente e é usada no cotidiano sem perceber. Algoritmos são sequências de passos para resolver problemas.
O documento apresenta um curso sobre gerenciamento de projetos de software. Ele discute a motivação para o curso, com estatísticas sobre o alto índice de falha em projetos de software devido à falta de gerenciamento de projetos. A agenda do curso é apresentada em três dias, cobrindo tópicos como gerenciamento de escopo, tempo, riscos, comunicações e custos. O curso também aborda a metodologia ágil SCRUM e inclui um exercício prático de gerenciamento de projeto em grupo.
1) O documento apresenta os conceitos fundamentais da teoria geral de sistemas e define o que é um sistema.
2) Apresenta as características básicas de um sistema e exemplos como automóveis, corpos humanos e computadores.
3) Discutem leis universais dos sistemas como a expansão e contração recursiva de subsistemas.
O documento fornece uma visão geral da arquitetura de software, discutindo sua importância, definições e histórico. A arquitetura de software emerge nos anos 80 como forma de estudar infraestruturas de software e agora oferece notações para ajudar no desenvolvimento de sistemas complexos. Uma boa arquitetura permite que um sistema atenda requisitos chaves, enquanto uma má pode ser desastrosa.
Diagrama Entidade Relacionamento - Bancos de Dados IDjonathas Cardoso
O documento apresenta os conceitos fundamentais de diagrama de entidade relacionamento, incluindo definição, entidades, atributos, relacionamentos e exemplos. Entidades representam objetos do mundo real sobre os quais se deseja manter informações, atributos são dados associados a cada ocorrência de uma entidade, e relacionamentos são associações entre entidades.
O documento discute a criação de modelos conceituais de bancos de dados, com foco em entidades e atributos. Ele apresenta exemplos de entidades em um sistema bancário, como clientes, contas e agências. Além disso, fornece dicas para identificar entidades a partir de um problema, como procurar substantivos, verbos e adjetivos que possam indicar entidades e atributos.
O documento explica o que é um diagrama de casos de uso, seus principais componentes e objetivos. Ele descreve como os diagramas de casos de uso mapeiam requisitos funcionais e servem como base para outros diagramas da UML, representando as interações entre atores e casos de uso de uma maneira abstrata e flexível.
O documento descreve uma aula prática sobre sistemas operacionais usando o simulador SOsim. A aula inclui seis práticas simulando processos, tipos de processos, PCB, estatísticas, log de execução e suspensão/eliminação de processos. O objetivo é apresentar conceitos como escalonamento de processos, CPU-bound vs I/O-bound e contexto de software e hardware.
Conceitos e princípios dos métodos ágeis, com foco no Scrum. Aborda também técnicas, cerimônias e ferramentas da gestão ágil. Apresentado para diversas áreas do Senado Federal, com o intuito de difundir as práticas para toda a organização.
1) A análise de requisitos é fundamental para obter um software de alta qualidade e envolve descobrir e refinar os requisitos através da comunicação entre cliente e desenvolvedor.
2) Os principais passos da análise incluem modelar o domínio da informação, desenvolver modelos do sistema, particionar o problema e especificar requisitos funcionais e não funcionais.
3) Uma especificação de requisitos efetiva separa funcionalidade de implementação, modela o sistema e seu ambiente, e é revisada para garantir completude e
O documento descreve modelos tradicionais e ágeis de engenharia de software, incluindo Cascata, Espiral, Processo Unificado, Crystal, Scrum e Programação Extrema. Os modelos tradicionais têm dificuldade em lidar com mudanças, enquanto os modelos ágeis enfatizam adaptação, colaboração com o cliente e entregas frequentes.
O documento explica os principais elementos de diagramas de casos de uso, incluindo atores, casos de uso, relacionamentos e cenários. Casos de uso representam funções do sistema, enquanto atores representam entidades externas. Há diferentes tipos de relacionamentos que podem existir entre casos de uso.
O documento apresenta um diagrama de classes para modelar um sistema de matrícula universitária. Ele descreve as classes Professor, Coordenador, Estudante, Turma, Disciplina, Formulário de Matrícula e Analisador de Matrícula e seus relacionamentos.
O documento discute conceitos de programação, como programas, gráficos de Gantt e programação para frente e para trás. A programação é o planejamento de volumes e horários em um ambiente. Gráficos de Gantt representam o tempo em barras para demonstrar quando tarefas começam e terminam. Sistemas de programação podem ser empurrados ou puxados, com diferentes vantagens e consequências.
O documento discute os conceitos fundamentais de arquitetura de software, incluindo: (1) arquitetura de software é o conjunto de estruturas que compõem um sistema, incluindo módulos, componentes e conectores, e alocação; (2) módulos dividem o sistema em unidades de implementação com responsabilidades específicas; (3) componentes e conectores representam elementos de software e suas interações em tempo de execução.
O documento discute os conceitos fundamentais de modelagem de dados, incluindo:
1) Entidades, atributos e chaves primárias definem as tabelas e campos do banco de dados.
2) Relacionamentos entre entidades representam como os dados serão ligados entre tabelas.
3) A normalização organiza os dados em tabelas separadas para evitar duplicação e inconsistências.
O documento descreve os componentes e construção de diagramas de sequência no UML. Especificamente, ele explica que diagramas de sequência ilustram a interação entre objetos através da troca de mensagens, e incluem atores, objetos, mensagens, linhas de vida e foco no controle para representar a criação e destruição de objetos.
O documento introduz conceitos básicos de engenharia de software, incluindo: (1) a definição de software e a crise histórica no desenvolvimento de software, (2) a introdução da engenharia de software para lidar com os desafios por meio de modelos de processo e gerenciamento de projetos, e (3) os principais modelos de processo e gerenciamento de projetos de software.
O documento apresenta os conceitos de diagramas de casos de uso. Explica que eles descrevem as interações entre atores e o sistema, sem detalhar como o sistema funciona internamente. Detalha os componentes de um diagrama de casos de uso, incluindo atores, casos de uso e associações, e fornece exemplos de cada um.
O documento discute métodos ágeis de desenvolvimento de software. Apresenta os problemas do desenvolvimento tradicional e descreve princípios como o Manifesto Ágil. Detalha práticas como XP e Scrum e fornece links para recursos adicionais sobre os tópicos discutidos.
O documento discute o que é lógica. A lógica procura compreender como pensamos de forma técnica e ensina a usar as leis do pensamento corretamente. A lógica é considerada uma ciência que organiza o pensamento corretamente e é usada no cotidiano sem perceber. Algoritmos são sequências de passos para resolver problemas.
O documento apresenta um curso sobre gerenciamento de projetos de software. Ele discute a motivação para o curso, com estatísticas sobre o alto índice de falha em projetos de software devido à falta de gerenciamento de projetos. A agenda do curso é apresentada em três dias, cobrindo tópicos como gerenciamento de escopo, tempo, riscos, comunicações e custos. O curso também aborda a metodologia ágil SCRUM e inclui um exercício prático de gerenciamento de projeto em grupo.
1) O documento apresenta os conceitos fundamentais da teoria geral de sistemas e define o que é um sistema.
2) Apresenta as características básicas de um sistema e exemplos como automóveis, corpos humanos e computadores.
3) Discutem leis universais dos sistemas como a expansão e contração recursiva de subsistemas.
O documento fornece uma visão geral da arquitetura de software, discutindo sua importância, definições e histórico. A arquitetura de software emerge nos anos 80 como forma de estudar infraestruturas de software e agora oferece notações para ajudar no desenvolvimento de sistemas complexos. Uma boa arquitetura permite que um sistema atenda requisitos chaves, enquanto uma má pode ser desastrosa.
Diagrama Entidade Relacionamento - Bancos de Dados IDjonathas Cardoso
O documento apresenta os conceitos fundamentais de diagrama de entidade relacionamento, incluindo definição, entidades, atributos, relacionamentos e exemplos. Entidades representam objetos do mundo real sobre os quais se deseja manter informações, atributos são dados associados a cada ocorrência de uma entidade, e relacionamentos são associações entre entidades.
O documento discute a criação de modelos conceituais de bancos de dados, com foco em entidades e atributos. Ele apresenta exemplos de entidades em um sistema bancário, como clientes, contas e agências. Além disso, fornece dicas para identificar entidades a partir de um problema, como procurar substantivos, verbos e adjetivos que possam indicar entidades e atributos.
Rodrigo Quites Reis apresentou sobre plataformas de software na IV Semana Acadêmica da Faculdade de Computação da UFPA em outubro de 2015. Ele definiu plataformas de software, explicou por que são importantes, e discutiu como projetá-las, incluindo a necessidade de considerar tanto os produtores quanto os consumidores. O documento forneceu exemplos atuais de plataformas e materiais de apoio sobre o assunto.
Introdução ao Projeto de Plataformas de Software: o quê, por que, comoRodrigo Reis
Este documento introduz o conceito de plataformas de software, discutindo o que é uma plataforma, por que são importantes e como projetá-las. Uma plataforma é definida como um ambiente de software que permite que terceiros criem aplicações acessando dados através de APIs. Plataformas são importantes pois permitem maior velocidade de desenvolvimento e mudam o paradigma de negócios para um modelo pull. Para projetar uma plataforma, deve-se identificar oportunidades, focar inicialmente em poucas APIs essenciais e consider
O documento descreve a arquitetura cliente-servidor da web, com foco nos protocolos HTTP e navegadores. Também discute linguagens de programação web como PHP, Ruby e ASP, além de frameworks como CodeIgniter e ferramentas como jQuery. Por fim, aborda APIs e os modelos REST e SOAP.
O documento discute os desafios comuns em projetos de software, como atrasos, aumento de custos e funcionalidades não entregues. Também apresenta os princípios e práticas do framework Scrum, como entregas incrementais frequentes, papéis, cerimônias e artefatos. Por fim, discute mitos e verdades sobre Scrum e Agilidade.
Este documento presenta un tutorial sobre el uso de la herramienta Visual Paradigm para modelar con UML. Se introduce Visual Paradigm y se describe un caso de estudio de un sistema de venta de entradas de cine. Luego, se muestran los pasos para crear diagramas de casos de uso, clases, y entidad-relación para el caso de estudio, así como la generación de código y base de datos a partir de los modelos. Finalmente, se resumen otras características de Visual Paradigm.
O documento fornece uma introdução ao framework Scrum para gerenciamento de projetos de software. Resume os principais pontos como: (1) Scrum é um framework ágil e iterativo para desenvolvimento de software; (2) Inclui papéis como Product Owner, ScrumMaster e time; (3) Utiliza eventos como sprints, reuniões diárias e revisões; (4) Tem como objetivo entregar valor ao cliente de forma incremental.
Desenvolvimento web - conceitos, tecnologia e tendências.Valmir Justo
O documento discute conceitos, tecnologias e tendências de desenvolvimento web. Aborda tópicos como HTML5, CSS3, frameworks responsivos, JavaScript, Node.js, linguagens e frameworks para desenvolvimento mobile, arquitetura empresarial e integração de sistemas. Apresenta também a agenda e perfil profissional do autor.
O documento descreve diferentes tipos de joins e subqueries no SQL, explicando suas funcionalidades e quando devem ser usadas. LEFT JOIN é usado para visualizar dados incluindo registros sem correspondência, enquanto subqueries permitem consultas aninhadas para encontrar dados relacionados. GROUP BY agrupa linhas com base em uma coluna para realizar contagens e outras agregações.
Este documento apresenta um treinamento sobre introdução à UML com casos de uso. O treinamento é ministrado por Rodrigo Gomes, que é analista de requisitos na IBM e professor universitário. O treinamento aborda conceitos básicos de UML, casos de uso, diagramas de casos de uso e levantamento de requisitos com casos de uso.
Apostila Modelo ER (Entidade Relacionamento)Ricardo Terra
O documento fornece o currículo de Ricardo Terra, incluindo seus detalhes de contato, formação acadêmica e experiência profissional. Ele também apresenta os conceitos básicos do modelo entidade-relacionamento (ER), incluindo entidades, relacionamentos e atributos.
O documento resume os principais tópicos sobre desenvolvimento de sistemas web, incluindo: (1) a diferença entre Internet e Web, como a Web usa a Internet para compartilhar hipertextos; (2) o modelo cliente-servidor e como ele funciona; (3) URLs e como elas localizam recursos na Web.
Este documento descreve os produtos da Oracle relacionados ao MySQL, incluindo o MySQL Community Edition licenciado sob GPL e o MySQL Enterprise Edition. Ele também lista 10 compromissos da Oracle com o MySQL e sua comunidade para manter o desenvolvimento do produto e suporte aos clientes.
Dentro do ciclo de desenvolvimento de um produto há várias atividades que vão desde a seleção da melhor tecnologia até boas práticas de manutenção em ambiente produtivo. Nesta apresentação mostramos algumas novidades do MySQL que ajudarão nestas tarefas associadas ao desenvolvimento de um excelente produto.
A UML surgiu da unificação de três linguagens de modelagem orientadas a objetos no final dos anos 1990. Tornou-se uma norma para modelagem de sistemas orientados a objetos, adotada mundialmente. A UML possui diversos diagramas para representar diferentes aspectos de um sistema, como classes, casos de uso, atividades e estados.
UML, Linguagem de Modelagem Unificada, é um padrão para modelagem visual de software.
Neste tutorial abordamos como utilizar a UML para fazer especificação de software através de conjunto de modelos e diagramas.
A modelagem visual facilita o entendimento e a comunicação do 'o quê' precisa ser feito e 'como' deverá ser feito o software;
1) O documento apresenta o método WAE para modelagem de aplicações web utilizando a linguagem UML, definindo novos estereótipos para representar elementos específicos da arquitetura web.
2) Apresenta os estereótipos de classe, como páginas do cliente e servidor, e de associação, como link e submit, utilizados na visão lógica do projeto web.
3) Discutem a visão de componentes da WAE, mapeando os elementos lógicos aos arquivos físicos por meio de diagram
Livro Programação em Shell 8 edição Julio Cézar NevezSoftD Abreu
Este documento fornece informações sobre programação Shell Linux, incluindo comandos básicos, manipulação de arquivos e diretórios, segurança de acesso, controle de execução e programação de tarefas agendadas. O documento também discute tópicos avançados como expressões regulares, programação condicional e funções Shell.
Apresentação sobre UML com foco nos Diagramas de Caso de Uso e Diagrama de Classes; apresentada na SESTINFO2009 (Semana de Estudos em Tecnologia da Informação) realizada na Universidade Metodista de São Paulo.
1) O documento apresenta as informações sobre a disciplina de Análise e Projeto de Sistemas Orientados a Objetos (APOO) ministrada pelo professor Ricardo Luiz.
2) A ementa descreve os principais tópicos abordados na disciplina, incluindo ciclo de vida de sistemas, modelagem com UML, ferramentas CASE e exercícios práticos.
3) O plano de aula detalha os temas que serão ensinados ao longo das aulas, como conceitos de orientação a objetos
O documento apresenta uma disciplina sobre desenvolvimento web com PHP orientado a objetos. Serão abordados os fundamentos do paradigma orientado a objetos aplicado em PHP, com foco em classes, objetos, métodos, construtores e destrutores. Os alunos desenvolverão um projeto em grupo aplicando os conceitos aprendidos.
Este documento apresenta o plano de aula de um curso de PHP e MySQL com 32 horas. O curso ensinará HTML, JavaScript, desenvolvimento web com PHP e integração com banco de dados MySQL. O plano detalha os tópicos a serem ensinados em cada aula e a avaliação inclui uma pesquisa, projetos semanais e um projeto final prático integrado com banco de dados.
1) O documento apresenta os principais tópicos a serem abordados em uma disciplina de Análise e Projeto de Sistemas, incluindo conceitos, metodologias, técnicas e ferramentas.
2) As competências e habilidades esperadas dos alunos incluem análise e projeto de sistemas, documentação, testes e aplicação de técnicas de programação orientada a objetos.
3) O curso utilizará o Processo Unificado (UP) e a Linguagem de Modelagem Unificada (U
Módulo 9 - Introdução à Programação Orientada a Objectos Luis Ferreira
Características da Programação Orientada por Objetos (POO).
Conceito de Classe, Atributos, Métodos, e Eventos.
Conceito de Objeto.
Conceito de Encapsulamento.
Conceito de Visibilidade de Classes, Métodos e Atributos.
Diagramas de Classe.
O ambiente de trabalho do Visual C#.
Objetos básicos e outras características básicas da linguagem do Visual C# e respetivo ambiente de trabalho.
O documento apresenta os principais conceitos da programação orientada a objetos, incluindo classes, objetos, atributos, métodos, encapsulamento, herança e polimorfismo. A linguagem Java é usada como exemplo para ilustrar esses conceitos-chave.
O documento apresenta o roteiro de uma aula inaugural de um curso de Programação Imperativa. Resume os principais tópicos como o docente, horário das aulas, frequência, plano de ensino, avaliação e bibliografia.
Webquest adição e subtracção de fracções, elvira ferreiraJoao Ferreira
Este documento fornece instruções para uma lição sobre adição e subtração de frações. Inclui tarefas para revisar conceitos básicos de frações, aprender sobre adição e subtração de frações com o mesmo denominador e com denominadores diferentes, e realizar exercícios de avaliação.
Este documento descreve um projeto de classificação de estilo de codificação Java usando aprendizado de máquina. O sistema irá aprender os critérios de nota de estilo de um professor e, após o treinamento, sugerir notas para códigos Java de alunos com base no estilo. O projeto envolveu desenvolver um parser para extrair métricas de códigos, experimentar com técnicas de classificação e seleção de atributos no Weka, e implementar uma ferramenta Java para treinar e classificar classificadores.
O documento apresenta uma metodologia para desenvolvimento de objetos de aprendizagem chamada INTERA. A metodologia propõe um processo iterativo com etapas de contextualização, requisitos, arquitetura, desenvolvimento e testes. Cada etapa produz artefatos que serão usados nas próximas etapas e objetiva garantir a qualidade pedagógica e técnica dos objetos desenvolvidos.
O documento resume uma aula sobre orientação a objetos. Resume três pontos principais:
1) Apresenta os objetivos da aula, que são introduzir conceitos de orientação a objetos como UML e como aplicá-los no Java.
2) Explica brevemente a história da orientação a objetos e algumas linguagens que a suportam como Java, C++ e PHP.
3) Discutem conceitos básicos como classes, atributos, métodos e objetos e como representá-los em UML e Java.
Este documento apresenta o plano de aula para a disciplina de Programação Orientada a Objetos I. O plano inclui o nome do professor, objetivos da disciplina, cronograma com 31 aulas ao longo do semestre abordando conceitos de Java e programação orientada a objetos, e critérios de avaliação com duas provas.
O documento apresenta uma introdução à Orientação a Objetos (OO) e à linguagem de modelagem UML. Aborda conceitos básicos de OO como objetos, classes, atributos, métodos, encapsulamento e herança. Também discute a história e vantagens da OO, além de apresentar os principais diagramas e ferramentas de apoio da UML.
Este documento apresenta um curso sobre desenvolvimento web com PHP orientado a objetos. Apresenta o professor e os objetivos da disciplina, além de referências bibliográficas e sites de apoio. Também descreve os paradigmas de programação procedural e orientado a objetos, conceitos importantes de PHP OO como classes, objetos, herança, polimorfismo, construtores e destrutores. Por fim, apresenta exemplos e exercícios para fixar os conceitos.
Metodologia e Linguagem de Programação - Aula 1Thyago Maia
O documento apresenta o professor e foco da disciplina de Metodologia e Linguagem de Programação. Apresenta também as ferramentas que serão utilizadas no curso, como o NetBeans IDE, livros adotados e redes sociais do professor. Explica brevemente sobre paradigmas de programação e como criar e testar um projeto simples em Java no NetBeans.
O documento discute conceitos de programação orientada a objetos como classes, objetos, encapsulamento, herança e polimorfismo. Também lista certificações da Oracle para Java SE 6 e 7.
O documento discute os principais conceitos da programação orientada a objetos, incluindo objetos, classes, atributos, comportamentos, métodos, mensagens, relacionamentos entre objetos e vantagens da POO. As classes definem os atributos e comportamentos compartilhados por objetos de um determinado tipo, enquanto os métodos implementam as operações de uma classe.
O documento descreve um projeto que criou um framework para gerenciar projetos usando Scrum em software livre. O framework permite criar projetos, usar quadros de tarefas Scrum e gráficos de queima de prazo. Testes com usuários mostraram melhorias no gerenciamento de tempo e relacionamento com clientes, mas o sistema precisa ser mais adaptável.
Apresentação do Projeto PRIME SCRUM. trabalho final do curso de Análise e Des...Thiago Barros, PSM
O documento discute o uso da metodologia Scrum para gerenciar projetos de software livre. Ele apresenta os problemas comuns em projetos de TI, como atrasos e estouro de orçamento, e propõe o uso de metodologias ágeis como Scrum para resolver esses problemas. O autor também descreve a criação de um framework para gerenciar projetos usando Scrum e as melhorias observadas nos processos de desenvolvimento após sua implementação.
Apresentação do Projeto PRIME SCRUM. trabalho final do curso de Análise e Des...
UML - parte 1
1. www.labes.ufpa.br
Abril
de
2015
ESPECIALIZAÇÃO
EM
P
PROJETO
DE
SOFTWARE
COM
UML
(DOCUMENTAÇÃO
DE
ARQUITETURA
DE
SOFTWARE)
PROF.
RODRIGO
QUITES
REIS
easo5ware,
ufpa,
2015
1
2. www.labes.ufpa.br
easo5ware,
ufpa,
2015
2
Obje9vo
da
Disciplina
• Fornecer
ao
aluno
a
capacitação
no
uso
de
UML
para
documentar
Requisitos
e
Arquitetura
de
So5ware
• Engenharia
Avante
– Construção
de
modelos
como
forma
de
se
refinar
o
entendimento
dos
requisitos,
estabelecer
o
comportamento,
e
gerar
código/esquemas
de
banco
de
dados
• Engenharia
Reversa
– Geração
de
documentação
a
par9r
de
so5ware
já
desenvolvido
3. www.labes.ufpa.br
Conteúdo
• Visão
Geral
sobre
o
Processo
de
Engenharia
de
So5ware
• Revisão
de
Orientação
a
Objetos
• UML
– Histórico
– Núcleo
da
UML
– Especificação
de
Requisitos
– Arquitetura
de
so5ware
• Exemplos
e
Exercícios
permeiam
a
disciplina
easo5ware,
ufpa,
2015
3
5. www.labes.ufpa.br
Antes
da
Orientação
a
Objetos
• Modelo
predominante:
Programação
Estruturada
– Estrutura
de
Sequência
• Ação1;
Ação2;
Ação3;
Ação4;
Ação5;
– Estrutura
de
Seleção
• Se,
então,
senão
– Estrutura
de
Repe9ção
• Repe9r
…
Até
;
• Enquanto
…;
easo5ware,
ufpa,
2015
5
6. www.labes.ufpa.br
Antes
da
Orientação
a
Objetos
• Programação
Estruturada
– Muito
código
foi
desenvolvido
e
con9nua
operacional
– Dificuldades
em
manter
e
reu9lizar
código
em
grande
escala
– Principais
unidades
de
manutenção/reuso:
• Módulos
funcionais
– Procedures
e
Func9ons
(Pascal)
– Func9ons
(em
C)
easo5ware,
ufpa,
2015
6
7. www.labes.ufpa.br
Antes
da
Orientação
a
Objetos
• Abstrações
Procedimentais
easo5ware,
ufpa,
2015
7
Problema
Proc
proc1;
Begin
...
End;
Proc
proc2(a,b,c);
Begin
...
End;
FuncJon
f1(x,
y);
Begin
...
End;
Begin
//
principal
End;
Programa
em
Pascal
Mapeamento
Mecanismos
de
abstração
da
Programação
Estruturada:
Procedimentos
e
funções
8. www.labes.ufpa.br
Orientação
a
Objetos
• Obje9vos
– Facilitar
o
mapeamento
do
Problema
para
Código
executável
• O
mundo
não
é
composto
por
procedimentos
• Estrutura
é
relacionável
com
Matemá9ca
Discreta
– Facilitar
a
manutenção
e
reu9lização
• Classes
são
cápsulas
que
englobam
(estruturas
de
dados
+
operações)
com
controle
de
acesso
• Modificações
tendem
a
ficar
restritas
a
um
módulo
easo5ware,
ufpa,
2015
8
9. www.labes.ufpa.br
Orientação
a
Objetos
• Conceitos
básicos
– Classe
&
Objeto
– Composição
de
objetos
– Herança
de
Classes
(sub-‐9pos)
– Método
&
Mensagem
easo5ware,
ufpa,
2015
9
10. www.labes.ufpa.br
Orientação
a
Objetos
• Abstração
Orientada
a
Objetos
easo5ware,
ufpa,
2015
10
Problema
Classe
Pessoa
{
...
}
Classe
Obra
{
...
}
void
main()
{
…
}
Programa
em
C++/Java
Mapeamento
Mecanismos
de
abstração
da
Orientação
a
Objetos:
Classes,
Métodos,
Herança,
Composição,
etc.
11. www.labes.ufpa.br
Orientação
a
Objetos
• Conceito:
Classe
– Definição
de
um
conjunto
de
objetos
que
compar9lham
estrutura
e
comportamento
comuns
– Objetos
são
criados
a
par9r
das
classes
– Na
construção
de
uma
classe,
a
abstração
mais
importante
diz
respeito
aos
dados
– O
principal
modelo
semân9co
adotado
é
a
Teoria
dos
Conjuntos
(para
definição
dos
dados)
easo5ware,
ufpa,
2015
11
12. www.labes.ufpa.br
Orientação
a
Objetos
• Conceito:
Classe
e
Objeto
easo5ware,
ufpa,
2015
12
Funcionário
Nome: João
Cargo: Analista
Grupo: Desenvolvimento
Nome: Maria
Cargo: Gerente
Grupo: Desenvolvimento
Classe
(conjunto)
Objetos
(elementos do
conjunto)
13. www.labes.ufpa.br
Orientação
a
Objetos
• O
uso
de
computador
é
baseado
em
abstrações
– Abstração:
representação
simplificada
da
realidade,
segundo
um
ponto
de
vista
– Exemplos:
• Zeros
e
Uns
para
representar
valores
de
portas
eletrônicas
de
um
computador
• Linguagens
de
Programação
• Interface
gráfica
baseada
em
Mouse
e
Janelas
easo5ware,
ufpa,
2015
13
17. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
– Influência
dos
circuitos
integrados
– Podem
ser
livremente
combinados
– Não
podem
ser
modificados
easo5ware,
ufpa,
2015
17
18. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
&
Mensagens
– “Muralha”
em
volta
do
objeto
– No
funcionamento
do
sistema,
objetos
respondem
mensagens
de
outros
objetos
– Alteração
no
estado
interno
do
objeto
só
através
dos
métodos
easo5ware,
ufpa,
2015
18
Objeto
Encapsulamento
20. www.labes.ufpa.br
Orientação
a
Objetos
• Encapsulamento
&
Mensagens
– Lei
de
Deméter
easo5ware,
ufpa,
2015
20
X
Y
z
obj
obj.mensagem(parâmetros)
mensagem(p)
begin
...
// qualquer valor manipulado aqui é x, y, z ou p.
end;
21. www.labes.ufpa.br
Orientação
a
Objetos
• Outros
elementos
importantes
– Classificação
• Associar
objetos
às
classes
– Associação
• Conexão
entre
objetos
– Agregação
• Um
objeto
é
composto
por
outro
– Generalização/Especialização
• Herança
easo5ware,
ufpa,
2015
21
23. www.labes.ufpa.br
Orientação
a
Objetos
• Associação
(ou
conexão)
entre
objetos
– Objetos
exis9ndo
de
forma
associada
– Poderoso
mecanismo
de
reu9lização
de
objetos
– Exemplo:
Biblioteca
easo5ware,
ufpa,
2015
23
Biblioteca
=
usuário
reserva
obra
24. www.labes.ufpa.br
Orientação
a
Objetos
• Agregação:
componentes
de
so5ware/hardware
easo5ware,
ufpa,
2015
24
System
Subsystem
1
Subsystem
2
Subsystem
3
Assembly
a
Assembly
b
Assembly
c
So5ware
Program
y
Hardware
Device
x
Notação
para
acesso
em
OO:
System.subsystem2.assemblyc.y
27. www.labes.ufpa.br
Orientação
a
Objetos
• Estado,
Comportamento
e
Iden9dade
de
Objetos
– Estado:
• Conjunto
de
valores
armazenados
em
um
objeto
– Comportamento:
• Ações
que
o
objeto
pode
realizar,
isto
é,
o
conjunto
de
métodos
implementados
na
classe
associada
– Iden9dade:
• Todo
objeto
é
criado
com
uma
chave
primária
implícita
determinada
pelo
sistema
(Object
Iden9fier
-‐
OID)
• O
OID
é
usado
para
definir
conexões
entre
objetos
easo5ware,
ufpa,
2015
27
28. www.labes.ufpa.br
Orientação
a
Objetos
• Estado,
Comportamento
e
Iden9dade
de
Objetos
easo5ware,
ufpa,
2015
28
Estado
Comportamento
IdenJdade
31. www.labes.ufpa.br
Orientação
a
Objetos
31
Processo
Top-‐Down
BD
Relacional
Classes
OO
Consulta
SQL
Métodos
(algoritmos)
easo5ware,
ufpa,
2015
32. www.labes.ufpa.br
Orientação
a
Objetos
• Orientação
a
Objetos
e
Modelo
Relacional
32
Banco de
Dados
Relacional
Interface
Gráfica
com
Usuário
Banco de
Dados
Relacional
Interface
Gráfica
com
Usuário
Modelo de
Objetos do
Negócio
Banco de
Dados
Relacional
Modelo de
Objetos do
Negócio
Interface
Gráfica c/
Usuário
Processo Bottom-Up Arquitetura de 3 camadas
easo5ware,
ufpa,
2015
33. www.labes.ufpa.br
O
Modelo
MPS
de
So5ware
e
seu
relacionamento
com
Análise/Projeto
de
Sistemas
easo5ware,
ufpa,
2015
33
34. www.labes.ufpa.br
MPS.BR
• MPS.BR
– Programa
de
Melhoria
do
Processo
de
So5ware
e
Serviços
de
TI
voltado
a
pequenas
e
médias
empresas
brasileiras
• MR-‐MPS-‐SW
– Modelo
de
Referência
para
Melhoria
do
Processo
de
So5ware
com
base
no
CMMi-‐DEV
– 600+
avaliações
realizadas
– Modelo
de
maturidade
brasileiro
Avaliação
da
qualidade
de
so5ware
através
do
seu
processo
de
construção
easo5ware,
ufpa,
2015
34
43. www.labes.ufpa.br
Histórico
da
UML
• Diversas
metodologias
e
métodos
surgiram
para
apoiar
OO
– Evolução
a
par9r
de
linguagens
C++
e
SmallTalk
– Anos
80-‐90:
diversidade
de
autores
– Anos
98-‐2000:
unificação
em
torno
de
UML
43
easo5ware,
ufpa,
2015
44. www.labes.ufpa.br
Histórico
da
UML
• Exemplos
de
Notações
– Classes
easo5ware,
ufpa,
2015
44
Booch
Schlaer-Mellor
OMTCoad-Yourdon
45. www.labes.ufpa.br
Histórico
da
UML
• A
diversidade
de
notações
para
representar
sistemas
orientados
a
objetos
nas
décadas
de
1980
e
1990
criou
o
caos
para
– Desenvolvedores
e
Empresas
de
So5ware
– Fabricantes
de
Ferramentas
– Treinamentos
• Cenário
ideal
para
unificação
em
torno
de
uma
única
notação
easo5ware,
ufpa,
2015
45
46. www.labes.ufpa.br
Histórico
da
UML
• Grady
Booch
– Um
dos
pioneiros
da
OO
– 1980:
ênfase
em
técnicas
de
projeto
para
Ada
– 1992-‐1994:
livros
• Object-‐Oriented
Design
with
Applica6ons
– projeto
de
programas
em
C++
e
Ada
easo5ware,
ufpa,
2015
46
Bastante
a9vo
no
Twiter
@Grady_Booch
47. www.labes.ufpa.br
Histórico
da
UML
• 1994:
Object-‐Oriented
Analysis
and
Design
with
Applica6ons
• texto
sobre
conceitos
de
OO
e
modelagem
de
objetos
• projeto
de
várias
aplicações-‐
exemplo
com
diferentes
linguagens
da
época
• base
de
UML
para
o
Design
– 1998:
Fundação
da
Ra9onal
easo5ware,
ufpa,
2015
47
48. www.labes.ufpa.br
Histórico
da
UML
• Ivar
Jacobson
– Modelagem
OO
baseado
em
Casos
de
Uso
– Objectory
• Processo
centrado
em
casos
de
uso
que
fornece
a
base
teórica
usada
atualmente
no
Unified
Process
easo5ware,
ufpa,
2015
48
49. www.labes.ufpa.br
Histórico
da
UML
• James
Rumbaugh
– Object
Modeling
Technique
(OMT)
– Desenvolvida
na
GE
– Metodologia
baseada
em
notações
pré-‐existentes
(ER,
DTE,
DFD)
– Clara
dis9nção
entre
as
três
visões
do
problema
– Base
da
UML
para
Análise
easo5ware,
ufpa,
2015
49
52. www.labes.ufpa.br
Histórico
da
UML
easo5ware,
ufpa,
2015
52
Metodologia Booch OMT
Unified Method 0.8OOPSLA ´95 Unified Method 0.8OOPSLA ´95
OOSEOutras metodologias
UML 0.9Web - June ´96
OOSEOutras metodologias
UML 0.9Web - June ´96 UML 0.9Web - June ´96 UML 0.9Web - June ´96
Período de
Feedback
público
Período de
Feedback
público
Submissão final ao OMG, Set ‘97
1a submissão ao OMG, Jan ´97
UML 1.1
Aceitação como padrão OMG, Nov 1997
Submissão final ao OMG, Set ‘97
1a submissão ao OMG, Jan ´97
UML 1.1
Aceitação como padrão OMG, Nov 1997
UML 1.4UML 1.4UML 1.4
UML 1.0Parceiros UML UML 1.0UML 1.0Parceiros UML
UML 2.1
OMG: Object Management Group
UML
2.4.1
53. www.labes.ufpa.br
Histórico
da
UML
easo5ware,
ufpa,
2015
53
Meyer
Before and after
conditions
Meyer
Before and after
conditions
Meyer
Before and after
conditions
Harel
Statecharts
Harel
Statecharts
Harel
Statecharts
Gamma, et al
Frameworks and patterns,
Gamma, et al
Frameworks and patterns,
Gamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and
message numbering
HP Fusion
Operation descriptions and
message numbering
HP Fusion
Operation descriptions and
message numbering
Embley
Singleton classes and
high-level view
Embley
Singleton classes and
high-level view
Embley
Singleton classes and
high-level view
Wirfs-Brock
Responsibilities
Wirfs-Brock
Responsibilities
Wirfs-Brock
Responsibilities
Odell
Classification
Odell
Classification
Odell
Classification
Shlaer - Mellor
Object lifecycles
Shlaer - Mellor
Object lifecycles
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Rumbaugh
OMT
Booch
Booch method
Booch
Booch method
Jacobson
OOSE
Jacobson
OOSE
54. www.labes.ufpa.br
Histórico
da
UML
• O
que
é
UML
– Linguagem
visual
para
especificação
(modelagem)
de
sistemas
orientados
a
objetos
• Fornece
representação
gráfica
para
os
elementos
essenciais
do
paradigma
de
objetos
– Classes,
atributos,
objetos,
troca
de
mensagens,
...
easo5ware,
ufpa,
2015
54
Pessoa
Comitê
Membro-‐de
Presidente-‐de
{subconjunto}
0..*
0..*
0..*
Telefone
Celular
Usuário
Uso
programado
55. www.labes.ufpa.br
Histórico
da
UML
• O
que
é
UML
– De
propósito
geral
• Não
está
presa
a
uma
etapa
do
desenvolvimento
de
so5ware
– Análise
– Projeto
– Implementação
– Testes
• Não
está
presa
a
um
processo
– Ciclo
de
vida
em
cascata
– Incremental
– Processo
Unificado
– ...
• Não
está
presa
a
uma
linguagem
de
programação
easo5ware,
ufpa,
2015
55
56. www.labes.ufpa.br
Histórico
da
UML
• UML
apóia
o
desenvolvimento
incremental
easo5ware,
ufpa,
2015
56
Usuário Serviço
habilita
data
**
Serviço
habilita
data
**
Serviço
Nome
Preço
Usuário
Nome
CPF
Serviço
habilita
data
**
Serviço
Nome
Preço
Usuário
Nome
CPF
suspende(período)
Modelos podem evoluir com a inclusão
de novos detalhes
Analogia: aula com transparências
sobrepostas
57. www.labes.ufpa.br
UML
• O
que
é
UML
– De
propósito
geral
• Não
está
presa
a
uma
linguagem
de
programação
easo5ware,
ufpa,
2015
57
Serviço
habilita
data
**
Serviço
Nome
Preço
Usuário
Nome
CPF
suspende(período)
public class Usuario {
private String nome;
private String cpf;
private Vector lnkServico;
}
Programador
Java
Possível
implementação
58. www.labes.ufpa.br
UML
• O
que
é
UML
– Padrão
OMG
• Em
htp://www.omg.org
estão
disponíveis
documentos
eletrônicos
que
contém
– Sumário
da
UML
– Semân9ca
– Guia
da
Notação
– Extensões
da
Linguagem
easo5ware,
ufpa,
2015
58
59. www.labes.ufpa.br
UML
• O
que
é
UML
– Privilegia
a
descrição
de
um
sistema
segundo
três
perspec9vas:
• Dados
(estrutural)
– Diagrama
de
Classes
• Operações
(funcional)
– Diagrama
de
Caso
de
Uso
• Eventos
(temporal/dinâmica)
– Diagramas
de
Seqüência,
A9vidades,
de
Transição
de
Estados
easo5ware,
ufpa,
2015
59
60. www.labes.ufpa.br
UML
• O
Processo
de
Análise
easo5ware,
ufpa,
2015
60
Funções
Dados
Problema
Análise
Eventos
Sistema
(conceitual)
(entrevistas,
leituras
especializadas,
brainstorming,
etc.)
61. www.labes.ufpa.br
UML
• O
Processo
de
Projeto
easo5ware,
ufpa,
2015
61
Funções
Dados Projeto
Eventos
Sistema
(conceitual)
(resultado da análise)
•Mapeamento
•Requisitos Arquiteturais
•Requisitos da plataforma
•Aspectos de deploy
Funções
Dados
Eventos
Outros Aspectos
67. www.labes.ufpa.br
• Alguns
critérios
para
avaliação
– Aspectos
comerciais:
preço,
disponibilidade
– Suporte
técnico
– Performance
– Usabilidade
– Exigências
de
Hardware
– Suíte
(cobre
todo
o
processo)
ou
Isolada
– Plataforma
de
Execução
– Integração
com
ferramentas
de
desenvolvimento
existentes
(IDEs,
Gerência
de
Requisitos,
etc)
– Geração
de
Código
e
Esquema
de
BD
(e
importação)
à
conhecido
em
inglês
como
round-‐trip
engineering
– ...
Como
estas
ferramentas
se
diferenciam
entre
si?
easo5ware,
ufpa,
2015
67
68. www.labes.ufpa.br
Casos
de
Uso
Notação
da
UML
e
especificações
textuais
suplementares
easo5ware,
ufpa,
2015
68
69. www.labes.ufpa.br
Casos
de
Uso
• Resumo
– Um
caso
de
uso
é
uma
forma
específica
de
uso
do
sistema
composta
por
uma
seqüência
de
ações
que
produz
um
resultado
de
valor
para
algum
agente
externo.
– Mostram
apenas
o
que
o
sistema
faz,
não
como.
– Capturam
o
comportamento
pretendido
para
um
sistema,
sem
a
necessidade
de
especificar
como
esse
comportamento
será
implementado.
easo5ware,
ufpa,
2015
69
70. www.labes.ufpa.br
Casos
de
Uso
• Um
caso
de
uso
realiza
um
aspecto
maior
da
funcionalidade
do
produto:
– deve
gerar
um
ou
mais
bene„cios
para
o
cliente
ou
para
os
usuários
– Podem
representar:
• roteiros
de
interação
com
usuário
• roteiros
do
manual
de
usuário
• casos
de
teste
easo5ware,
ufpa,
2015
70
Filho,
W.P.P
em
“Engenharia
de
So5ware:
Fundamentos,
Métodos
e
Padrões”
71. www.labes.ufpa.br
Casos
de
Uso
• Casos
de
Uso
(CDU)
– Técnica
para
documentar
os
requisitos
potenciais
para
um
novo
sistema
ou
para
uma
modificação
em
um
so5ware;
– Cada
CDU
provê
um
ou
mais
cenários
que
descrevem
como
o
sistema
deve
interagir
com
seus
usuários
finais
ou
outros
sistemas
para
a9ngir
um
obje9vo
de
negócio;
– CDUs
devem
evitar
jargão
técnico,
usando
ao
invés
a
linguagem
do
usuário
ou
do
especialista
de
domínio.
easo5ware,
ufpa,
2015
71
72. www.labes.ufpa.br
Casos
de
Uso
• CDUs
não
descrevem
o
funcionamento
interno
de
um
sistema
tampouco
explicam
como
o
sistema
deve
ser
implementado
• Ao
invés,
mostram
os
passos
que
um
usuário
deve
seguir
para
realizar
uma
tarefa.
• Um
CDU
define
interações
entre
atores
externos
e
o
sistema
sob
consideração
para
se
a9ngir
um
obje9vo
de
negócio.
• Atores
são
en9dades
externas
ao
sistema.
Um
ator
pode
ser
uma
classe
de
usuários,
um
papel
que
usuários
podem
desempenhar,
ou
outro
sistema.
easo5ware,
ufpa,
2015
72
73. www.labes.ufpa.br
Casos
de
Uso
• CDUs
são
efe9vos
para
descrever
requisitos
funcionais,
mas
não
para
todos
os
9pos
de
projetos.
CDUs
focalizam
nas
interações
de
um
usuário
com
o
sistema,
ou
em
interações
sistema
a
sistema.
• Contudo,
não
são
úteis
em
projetos
onde
a
complexidade
não
está
associada
com
a
intera9vidade,
e
sim
com
a
funcionalidade
interna
– P.Ex:
Processamento
batch,
Data
Wareshousing,
cálculos
complexos
• CDUs
também
não
são
adequados
para
descrever
requisitos
não
funcionais.
Entretanto,
o
raciocínio
em
cima
de
CDUs
pode
ser
ú9l
para
iden9ficar
requisitos
de
performance.
easo5ware,
ufpa,
2015
73
74. www.labes.ufpa.br
Casos
de
Uso
• Casos
de
uso
servem
como
guia
para:
– Criação
e
validação
da
arquitetura
do
sistema.
– Definição
de
casos
e
procedimentos
de
testes.
– Planejamento
da
iterações,
elaboração
de
cronograma,
organização
do
9me.
– Criação
da
documentação
do
usuário.
easo5ware,
ufpa,
2015
74
75. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Notação
Gráfica
easo5ware,
ufpa,
2015
75
Caixa
eletrônico
Consultar
saldo
Solicitar
extrato
Realizar
SaqueCliente Funcionário
Abastecer
dinheiro
Recolher
envelopes de
depósitos
[Furlan98]
Realizar
depósito
76. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Notação
gráfica
(em
ferramenta
CASE)
easo5ware,
ufpa,
2015
76
Consultar saldo
Emitir extrato
Realizar saque
Cliente
Realizar depósito
Retirar envelopes de depósito
Funcionário
Abastecer com dinheiro
77. www.labes.ufpa.br
Casos
de
Uso
• Oferecem
uma
maneira
intui9va
e
sistemá9ca
para
capturar
os
requisitos
FUNCIONAIS
• Foco
no
conceito
de
“valor
adicionado”
(added
value)
ao
cliente
• Podem
ser
u9lizados
para
guiar
o
processo
de
desenvolvimento
easo5ware,
ufpa,
2015
77
[Unified
So5ware
Development
Process
–
Jacobson,
Booch,
Rumbaugh]
78. www.labes.ufpa.br
“Valor
adicionado”
• Perguntar
aos
clientes/usuários
o
que
eles
gostariam
que
o
sistema
fizesse
não
funciona:
– Lista
de
funcionalidades
que
pode
parecer
ú9l
a
princípio,
mas
na
verdade...
• Ex:
modificar
endereço
da
cobrança
• Estratégia
de
Caso
de
Uso:
– Refrazear
para
“O
que
você
quer
que
o
sistema
faça
PARA
CADA
USUÁRIO?”
easo5ware,
ufpa,
2015
78
79. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Notação
-‐
Elementos:
easo5ware,
ufpa,
2015
79
Ator
Ator. Elemento externo do sistema que sempre
inicia o uso ou recebe um valor do caso de uso
Caso de Uso. Serviço que o sistema fornece aos usuários.
Sistema
Caso de uso 1
Interação. Estímulos recebidos pelo sistema.
Sistema. Contexto aonde o caso de uso é utilizado
80. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
CDU
– Normalmente
associado
com
uma
tela
de
entrada
e/ou
saída
de
dados,
ou
um
relatório
easo5ware,
ufpa,
2015
80
81. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-‐
Cenário
– Exemplo
(Realizar
Saque):
• Saque
com
sucesso
• Tenta9va
de
saque
MAS
senha
incorreta
• Tenta9va
de
saque
MAS
saldo
insuficiente
– Cada
caso
de
uso
encapsula
uma
coleção
de
cenários,
tanto
de
sucesso
como
de
falha.
easo5ware,
ufpa,
2015
81
Cliente
Realizar saque
82. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-‐
Ator
– Qualquer
coisa
que
possui
interface
com
o
sistema
a
ser
desenvolvido
– Definem
um
papel
par9cular
exercido
por
uma
coisa
ou
pessoa
– São
sempre
externos
ao
sistema
easo5ware,
ufpa,
2015
82
Cliente
Exemplo
de
Ator:
(Sempre
com
aparência
humanóide)
83. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Ator
– Uma
mesma
pessoa
pode
desempenhar
diferentes
papéis
em
um
sistema
– Cada
papel
é
representado
por
um
ator.
easo5ware,
ufpa,
2015
83
Funcionário Administrador
Beltrano
Papéis
que
pode
exercer
84. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-‐
Pacotes
– Servem
para
agrupar
casos
de
uso
relacionados
– Critérios
para
agrupamento:
• Ator
• Funcionalidades
correlatas
• Processos
easo5ware,
ufpa,
2015
84
Consultar saldo
Emitir extrato
Realizar saque
Cliente
Realizar depósito
PacoteCliente
85. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Comunicação
Ator
e
CDU
– Representa
quais
atores
estão
ligados
a
quais
casos
de
uso
easo5ware,
ufpa,
2015
85
Telefone
Celular
A comunicação é representada através
de um arco simples
Usuário
Fazer ligação
86. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Tipos
de
Interação
– Inclusão
• Um
caso
inclui
(precisa
de,
é
composto
de)
outro
• Representada
através
de
um
arco
pon9lhado
com
o
rótulo
<<inclui>>
ou
<<include>>
(UML
1.4+)
ou
<<uses>>
(UML
1.3-‐)
• Normalmente
um
CDU
componente
é
usado
em
mais
de
um
outro
easo5ware,
ufpa,
2015
86
Telefone
Celular
Usuário
Fazer ligação Identificar destinatário
<<include>>
87. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Tipos
de
Interação
– Extensão
• Um
caso
de
uso
pode
opcionalmente
u9lizar
um
outro
easo5ware,
ufpa,
2015
87
Telefone
Celular
Usuário
Receber ligação
Receber Ligação Adicional
<<extend>>
Opcional
88. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Extensão
easo5ware,
ufpa,
2015
88
Servir entrada Servir sobremesa
Servir refeição
<<extend>>
<<extend>>
89. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
-‐
Herança
– Generalização
/
Especialização
• Pode
ser
aplicada
para
CDU
e
Ator
easo5ware,
ufpa,
2015
89
Super tipo
Sub tipos
Pagamento a vista Pagamento com cartão
Usuário Efetua pagamento
90. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Herança
– Herança
de
Atores
easo5ware,
ufpa,
2015
90
Administrador
Usuário Visitante
Correto?
Usuário
não
é
um
9po
de
Visitante
91. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Herança
– Herança
de
Atores
easo5ware,
ufpa,
2015
91
Atendente
Realiza venda
Gerente
Cancela venda
<<extend>>
Consulta estoque
Funcionário
92. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
easo5ware,
ufpa,
2015
92
Busca itens
Cliente
Solicita ajuda Sistema de ajuda online
Realiza pedido
Processador de pagamentos
Tempo
Realiza pagamento de impostos
Autoridade de impostos
1o release
2o release
3o release
93. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
-‐
Telefone
Celular
easo5ware,
ufpa,
2015
93
Telefone
Celular
Usuário
Rede
Celular
Fazer
ligação
Receber
ligação
Fazer
uso
programado
Fazer
ligação
em
conferência
Receber
ligação
adicional
<<extend>>
<<extend>>
Iden9ficar
des9natário
<<include>>
94. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
easo5ware,
ufpa,
2015
94
Cliente
Cliente
Pessoa
Física
Cliente
Pessoa
Jurídica
Sistema
de
Venda
com
Cartão
de
Crédito
Varejista
Administradora
de
cartão de
crédito
Transação
Venda
Cancelamento
de
venda
<<extends>>
Obs:
padrão
de
análise
95. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Caso
de
Uso
Transação
– Abstrato
• É
usado
como
generalização
– É
usado
para
representar
serviços
da
organização
que
precisam
ter
a
sua
ocorrência
registrada
• O
registro
obrigatoriamente
contém
– o
momento
em
que
ocorreu
a
transação
(data/hora)
– quem
par9cipou
(cliente
e
vendedor)
– o
quê
esteve
envolvido
(o
produto
da
venda)
easo5ware,
ufpa,
2015
95
96. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Exemplo
–
Máquina
de
Venda
de
Bebidas
easo5ware,
ufpa,
2015
96
Vender bebida
Consumidor
Abrir máquina
Fechar máquina
Fornecedor
Repor Bebidas
<<include>>
<<include>>
Dono
Retirar dinheiro
<<include>>
<<include>>
99. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Granularidade
de
CDUs
– Um
CDU
deve
representar
uma
unidade
de
funcionalidade
menor
possível,
que
uma
vez
implementada,
acrescenta
valor
(do
ponto
de
vista
dos
autores)
ao
sistema
– Exemplo
em
ATM
bancário
• “Introduzir
cartão”
não
é
CDU
(não
tem
valor
isoladamente)
• “Realizar
saque”
é
CDU
pois
tem
valor
para
o
corren9sta
easo5ware,
ufpa,
2015
99
100. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Granularidade
de
CDUs
– Devido
a
dúvida
sobre
o
valor
de
CDUs,
o
processo
de
modelagem
é
normalmente
itera9vo
easo5ware,
ufpa,
2015
100
101. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Heurís9cas
(1)
– Evitar
um
número
muito
elevado
de
casos
de
uso
• Fragmentar
o
sistema
em
sub-‐sistemas
(ou
em
sub-‐pacotes)
• Usar
casos
de
uso
com
denominação
genéricas
como
Manter
ou
Gerenciar
para
descrever
as
funções
de
Cadastro
de
uma
en9dade
• Evitar
detalhamento
algorítmico
easo5ware,
ufpa,
2015
101
102. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Heurís9cas
(2)
– Diagramas
de
Caso
de
Uso
têm
sido
usados
para
auxiliar
no
diálogo
do
usuário
– Deve-‐se
ter
atenção
para
o
fato
que
o
diagrama
tem
semân9ca
informal
• Isto
é,
não
é
preciso
• Para
um
mesmo
problema,
múl9plas
soluções
válidas
são
admi9das
• Exige
descrição
textual
para
elucidação
easo5ware,
ufpa,
2015
102
103. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Heurís9cas
(3)
– Evitar
o
uso
de
<<include>>
e
<<extend>>
nas
primeiras
iterações
easo5ware,
ufpa,
2015
103
104. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Conceito
–
Modelo
de
Casos
de
Uso
– Modelo
que
descreve
os
casos
de
uso
do
sistema
e
atores
relacionados.
– Diagramas
e
especificações
textuais
Atores Casos de Uso
Especificações de casos de uso
easo5ware,
ufpa,
2015
104
105. www.labes.ufpa.br
Como
encontrar
Atores
e
CDUs?
• Atores
e
CDUs
são
elementos
de
primeira
ordem
– Atores:
papéis
desempenhados
por
usuários
ou
sistemas
externos
– CDUs:
serviços
fornecidos
pelo
sistema
novo
sendo
concebido
easo5ware,
ufpa,
2015
105
106. www.labes.ufpa.br
Como
encontrar
atores?
• Quem
usa
o
sistema?
• Quem
instala/mantém
o
sistema?
• Quem
inicia/desliga
o
sistema?
• Que
outros
sistemas
usam
o
sistema?
• Quem
recebe
informação
do
sistema?
• Quem
provê
informação
ao
sistema?
easo5ware,
ufpa,
2015
106
107. www.labes.ufpa.br
Como
encontrar
casos
de
uso?
• Atores
são
fundamentais
para
a
descoberta
dos
casos
de
uso
• Pergunte:
– Que
funções
o
ator
vai
querer
do
sistema?
– O
sistema
armazena
informações?
Que
informações
atores
irão
criar,
ler,
atualizar
ou
apagar?
– O
sistema
precisa
no9ficar
o
ator
sobre
mudanças
no
seu
estado
interno?
– Existe
algum
evento
externo
que
o
sistema
precisa
saber?
Que
ator
informa
o
sistema
desses
eventos?
easo5ware,
ufpa,
2015
107
108. www.labes.ufpa.br
Escopo
do
sistema
• É
preciso
delimitar
as
fronteiras
do
sistema
– Se
a
fronteira
for
o
círculo
interno,
então
Caixa
e
o
Sistema
Bancário
são
atores
e
não
precisarão
ser
implementados.
Cliente
Caixa
easo5ware,
ufpa,
2015
108
Sistema BancárioSistema de
Caixa Automático
Qual é a
fronteira
do sistema?
110. www.labes.ufpa.br
Quando
e
por
que
realizá-‐las?
• Quando?
– Após
fazer
levantamento
dos
principais
casos
de
uso
do
sistema.
• Por
que?
– Descrever
detalhes
dos
casos
de
uso
– Descrever
fluxos
de
eventos
e
outras
propriedades
– Uniformizar
entendimento
entre
clientes,
usuários
e
equipe
de
desenvolvimento.
easo5ware,
ufpa,
2015
110
111. www.labes.ufpa.br
Especificando
casos
de
uso
• Casos
de
uso
não
precisam
ser
especificados
todos
de
uma
vez
• Casos
de
uso
devem
ser
priorizados
por
iteração
– Prioridade
técnica
– Prioridade
do
usuário
easo5ware,
ufpa,
2015
111
112. www.labes.ufpa.br
Especificação
de
um
caso
de
uso
• Iden9ficador
• Nome
e
breve
descrição
• Ator(es)
• Prioridade
• Requisitos
não
funcionais
associados
• Pré-‐condições
• Pós-‐condições
• Fluxo
de
eventos
principal
• Fluxos
secundários:
alterna9vos
e
de
exceção
easo5ware,
ufpa,
2015
112
113. www.labes.ufpa.br
Iden9ficação
do
caso
de
uso
easo5ware,
ufpa,
2015
113
• Deve
ser
única
• Não
deve
mudar
nunca,
pois
casos
de
uso
podem
ser
referenciados
por
seu
iden9ficador.
114. www.labes.ufpa.br
Breve
descrição
do
caso
de
uso
easo5ware,
ufpa,
2015
114
• Dar
uma
idéia
do
propósito
do
caso
de
uso,
do
seu
obje9vo
• Deve
ser
feita
ao
se
iden9ficar
o
caso
de
uso,
para
evitar
mal-‐entendidos
• 2
ou
3
linhas!
115. www.labes.ufpa.br
Atores
• Descrição
dos
atores
envolvidos
com
o
caso
de
uso
easo5ware,
ufpa,
2015
115
Usuário
Fazer ligação
Atores
Descrição
Usuário
É
o
responsável
por
iniciar
e
o
principal
interessado
na
realização
de
uma
ligação.
Para
tanto,
deve
ser
cliente
de
uma
operadora
de
telefonia
celular.
116. www.labes.ufpa.br
Prioridades
de
casos
de
uso
easo5ware,
ufpa,
2015
116
• Essencial
para
gerenciar
requisitos
e
para
montar
iterações
• Definir
prioridade
de
todos
os
casos
de
uso
• Exemplo
de
classificação
da
prioridade:
– Essencial
– Importante
– Desejável
117. www.labes.ufpa.br
Pré
e
pós
condições
• O
que
deve
ser
verdade
antes
e
depois
da
realização
do
caso
de
uso!
– Pré-‐condição:
• estado
em
que
o
sistema
deve
estar
para
realizar
o
caso
de
uso.
– Pós-‐condição:
• lista
de
possíveis
estados
em
que
o
sistema
pode
estar
imediatamente
após
o
término
da
realização
do
caso
de
uso.
easo5ware,
ufpa,
2015
117
118. www.labes.ufpa.br
Pré
e
pós
condições:
exemplos
• Caso
de
uso
“Entregar
pedido”
– Pré-‐condição:
Os
itens
do
pedido
devem
exis9r
em
estoque
– Pós-‐condição:
Os
itens
enviados
devem
ser
aba9dos
do
estoque.
• Caso
de
uso
“Recadastramento
de
CPF”
– Pré-‐condição:
o
usuário
deve
possuir
um
CPF
– Pós-‐condição:
a
situação
do
contribuinte
é
atualizada.
easo5ware,
ufpa,
2015
118
119. www.labes.ufpa.br
Fluxo
de
eventos
básico
ou
principal
• Funcionalidade
básica
ou
central
do
caso
de
uso
• Representa
o
caminho
que
é
seguido
na
maioria
das
vezes
que
o
caso
de
uso
é
executado.
• Descreve
a
situação
mais
simples
do
caso
de
uso,
na
qual
o
obje9vo
é
a9ngido.
• Pense
nos
fluxos
secundários
depois!
easo5ware,
ufpa,
2015
119
120. www.labes.ufpa.br
Exemplo
de
um
fluxo
básico
• Caso
de
uso
“Sacar
dinheiro”
1. O
cliente
passa
o
cartão
2. O
sistema
solicita
senha
e
valor
do
saque
3. O
cliente
digita
os
valores
solicitados
4. O
sistema
verifica
se
há
saldo
suficiente
5. O
sistema
debita
da
conta
do
cliente
o
valor
do
saque.
6. O
dinheiro
é
entregue
ao
cliente.
easo5ware,
ufpa,
2015
120
121. www.labes.ufpa.br
Exemplo
de
um
fluxo
básico
• Caso
de
uso
“Sacar
dinheiro”
• MAS...
– E
se
a
senha
não
conferir?
– E
se
não
houver
saldo?
– E
se
não
houver
dinheiro
suficiente
na
máquina?
Calma,
vamos
deixar
esses
detalhes
para
depois!
easo5ware,
ufpa,
2015
121
122. www.labes.ufpa.br
• Pré-‐condição:
usuário
não
está
suspenso
• 1.
Usuário
solicita
um
item
do
acervo
• 2.
Funcionário
verifica
disponibilidade
do
item
solicitado
• 3.
Sistema
informa
a
localização
do
item
• 4.
Funcionário
registra
o
emprés9mo
• 5.
O
sistema
emite
um
comprovante
do
emprés9mo
(em
duas
vias)
easo5ware,
ufpa,
2015
122
123. www.labes.ufpa.br
Subfluxos
• As
vezes,
o
fluxo
principal
possui
várias
alterna9vas
igualmente
prováveis
de
ocorrer
• Nestes
casos,
pode-‐se
usar
o
conceito
de
subfluxos
• Cada
subfluxo
representa
um
dos
possíveis
caminhos
do
fluxo
principal
easo5ware,
ufpa,
2015
123
124. www.labes.ufpa.br
Subfluxos
-‐
Exemplo
• Caso
de
uso
“Cadastrar
Produtos”
– Fluxo
básico
1. O
funcionário
seleciona
a
opção
de
cadastro,
iniciando
o
caso
de
uso.
2. O
sistema
solicita
que
o
funcionário
indique
a
operação
que
deseja
efetuar:
inclusão,
atualização
ou
remoção
de
produtos.
3. De
acordo
com
a
opção
fornecida
pelo
funcionário,
um
dos
subfluxos
abaixo
é
executado.
easo5ware,
ufpa,
2015
124
125. www.labes.ufpa.br
Subfluxos
–
Exemplo
(2)
– Subfluxo
Incluir
produto
1. O
sistema
solicita
o
nome,
descrição
e
preço
do
novo
produto.
2. O
funcionário
fornece
os
dados
3. O
sistema
gera
um
iden9ficador
único
para
o
produto
e
o
armazena
as
informações
fornecidas.
– Subfluxo
Alterar
informações
do
produto
1. O
sistema
solicita
o
nome
ou
iden9ficador
do
produto
a
ser
alterado.
2. O
funcionário
fornece
o
iden9ficador
do
produto.
3. Os
sistema
apresenta
os
dados
do
produto
para
alteração
(os
mesmos
dados
solicitados
no
subfluxo
“Incluir
produto”)
4. O
funcionário
atualiza
os
dados
do
produto
e
o
sistema
armazena
os
novos
dados.
– Subfluxo
Remover
produto
...
easo5ware,
ufpa,
2015
125
126. www.labes.ufpa.br
Fluxos
secundários
• Só
devem
ser
analisados
e
descritos
após
a
descrição
dos
fluxos
básicos.
– Para
cada
CDU,
perguntar:
“o
que
pode
dar
errado?”,
“o
que
pode
ser
diferente?”
• Fluxos
alterna9vos
– Situações
especiais
(desconto
para
um
cliente)
• Fluxos
de
erro
– Situações
de
erro
easo5ware,
ufpa,
2015
126
127. www.labes.ufpa.br
Reuso
de
fluxos
secundários
• Fluxos
secundários,
principalmente
de
erros,
podem
ser
referenciados
por
diferentes
casos
de
uso
• Evitar
duplicação
de
informação!
easo5ware,
ufpa,
2015
127
128. www.labes.ufpa.br
Resumo
–
Fluxos
de
eventos
easo5ware,
ufpa,
2015
128
• Fluxo
normal
ou
básico
(“Happy
Path”)
– Pode
conter
subfluxos
• Fluxos
alterna9vos
– Variações
regulares
– Casos
incomuns
• Fluxos
de
exceção
– Tratam
situações
de
erro
do
fluxo
básico.
129. www.labes.ufpa.br
Requisitos
não
funcionais
associados
• Listar
RNFs
associados
ao
CDU
específico
– Exemplos:
• Tempo
de
resposta
(máximo
de
2
seg
para
100
transações
concorrentes)
• Segurança:
Controle
de
acesso
• …
easo5ware,
ufpa,
2015
129
133. www.labes.ufpa.br
Modelagem
de
Casos
de
Uso
• Comentário
Final
– Os
casos
de
uso
são
elementos
muito
importantes
no
Processo
Unificado
– Todas
as
a9vidades
de
desenvolvimento
são
organizadas
em
função
dos
casos
de
uso
easo5ware,
ufpa,
2015
133
134. www.labes.ufpa.br
Papel
do
Modelo
de
CDU
no
Processo
easo5ware,
ufpa,
2015
134
Fonte: Alexandre Vasconcelos - O Fluxo de Requisitos
135. www.labes.ufpa.br
Checklists:
Modelo
de
Casos
de
Uso
• O
modelo
de
caso
de
usos
está
fácil
de
se
entender?
• Estudando
o
modelo
de
caso
de
usos,
você
pode
ter
uma
idéia
clara
das
funções
do
sistema
e
como
elas
estão
relacionadas?
• Todos
os
requisitos
foram
levantados?
• O
modelo
de
caso
de
usos
contém
algum
comportamento
supérfluo?
• A
divisão
em
pacotes
do
modelo
de
caso
de
usos
está
apropriada?
easo5ware,
ufpa,
2015
135
136. www.labes.ufpa.br
Checklists:
Atores
• Todos
os
atores
foram
iden9ficados?
• Cada
ator
está
envolvido
com
pelo
menos
um
caso
de
uso?
• Cada
ator
desempenha
um
papel?
Algum
deveria
ser
fundido
com
outro
ou
ser
dividido
em
dois?
• Existem
dois
ou
mais
atores
desempenhando
o
mesmo
papél
em
relação
a
um
caso
de
uso?
• Os
atores
têm
nomes
intui9vos
e
descri9vos?
Tanto
os
usuários
como
os
patrocinadores
do
so5ware
têm
um
entendimento
comum?
easo5ware,
ufpa,
2015
136
137. www.labes.ufpa.br
Checklists:
Casos
de
Uso
• Cada
caso
de
uso
está
envolvido
com
pelo
menos
um
ator?
• Os
caso
de
usos
são
independentes
uns
dos
outros?
• Algum
dos
caso
de
usos
tem
comportamento
ou
fluxo
de
eventos
muito
similares?
• Os
caso
de
usos
têm
nomes
únicos,
intui9vos
e
explica9vos
de
modo
que
não
podem
ser
confundidos
em
um
estágio
posterior?
• Os
patrocinadores
e
usuários
entendem
os
nomes
e
descrições
dos
caso
de
uso?
easo5ware,
ufpa,
2015
137
138. www.labes.ufpa.br
Checklists:
Especificação
de
Caso
de
Uso
• Está
claro
quem
deseja
executar
um
caso
de
uso?
• A
finalidade
de
cada
caso
de
uso
está
clara?
• A
descrição
breve
dá
uma
idéia
clara
do
significado
do
caso
de
uso?
• Está
claro
como
e
quando
os
fluxos
de
eventos
de
cada
caso
de
uso
começam
e
terminam?
• A
seqüência
de
comunicação
entre
um
ator
e
um
caso
de
uso
está
de
acordo
com
as
expecta9vas
do
usuário?
• As
interações
e
trocas
de
informação
entre
os
atores
e
o
sistema
estão
claras?
• Existe
algum
caso
de
uso
demasiadamente
complexo?
• Os
fluxos
de
eventos
(básicos
e
alterna9vos)
estão
modelados
de
forma
clara?
easo5ware,
ufpa,
2015
138
140. www.labes.ufpa.br
Processo
Simplificado
• Artefatos
easo5ware,
ufpa,
2015
140
Sistema
Usuário
XPTO
Diagrama
de
Casos
de
Uso
Diagrama
de
Classes
: Atendente: Atendente
Tela de Geração
de Conta
Tela de Geração
de Conta
: Sessão: Sessão : Item: Item
conta : Contaconta : Conta
: Promoção: Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência
e
Colaboração
Planejado
Cancelado
transferência( novaData, novaHora ) /
data := novaData; hora := novaHora
Pago
Realizado
Realizado com
pagamento pendente
Realizado com
pagamento antecipado
Realizado com
pagamento pendente
pagamentoEfetuado Realizado com
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual,
motivo=paciente)
solicitaçãoMédico / criarCancelamento(dataHoraAtual,
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
Diagrama
de
Estados
Diagrama
de
AJvidades
141. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
artefatos
(1)
easo5ware,
ufpa,
2015
141
Sistema
Usuário
XPTO
Diagrama
de
Casos
de
Uso
: Atendente: Atendente
Tela de Geração
de Conta
Tela de Geração
de Conta
: Sessão: Sessão : Item: Item
conta : Contaconta : Conta
: Promoção: Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência
e
Colaboração
Fornece
os
cenários
Valida
as
interações
142. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
artefatos
(2)
easo5ware,
ufpa,
2015
142
Sistema
Usuário
XPTO
Diagrama
de
Casos
de
Uso
Diagrama
de
Classes
Fornece
os
cenários
Validas
as
interações
(*)
(*)
isto
é,
se
não
forem
achadas
as
classes
envolvidas
em
um
CDU,
há
indícios
que
não
se
trata
de
um
CDU
em
si.
143. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
Artefatos
(3)
easo5ware,
ufpa,
2015
143
Diagrama
de
Classes
: Atendente: Atendente
Tela de Geração
de Conta
Tela de Geração
de Conta
: Sessão: Sessão : Item: Item
conta : Contaconta : Conta
: Promoção: Promoção
1: gerarContaSessão(s)
2: obter(s)
3: s
4: obterItensConsumidos
5: obterItens
6: itens
7: itens
10: obterPreço
11: preçoUnitário
12: obterQuantidade(item)
13: quantidade
8: obterNome
9: nome
repetir enquanto houver itens na sessão de consumo
15: criar(s, itens)
16: conta
17: conta
14:
Diagrama
de
Sequência
e
Colaboração
Fornece
objetos
e
classes
Valida
o
modelo
e
fornece
detalhes
(atributos
e
operações)
144. www.labes.ufpa.br
Processo
Simplificado
• Relacionamento
entre
Artefatos
(4)
easo5ware,
ufpa,
2015
144
Diagrama
de
Classes
Planejado
Cancelado
transferência( novaData, novaHora ) /
data := novaData; hora := novaHora
Pago
Realizado
Realizado com
pagamento pendente
Realizado com
pagamento antecipado
Realizado com
pagamento pendente
pagamentoEfetuado Realizado com
pagamento antecipado
solicitaçãoPaciente / criarCancelamento(dataHoraAtual,
motivo=paciente)
solicitaçãoMédico / criarCancelamento(dataHoraAtual,
motivo=médico)
autorização( dataHoraAutorização, códigoAutorização, convênio )[ tipo == convênio
] / criarAutorização(dataHoraAutorização, códigoAutorização, convênio)
pagamentoEfetuado[ tipo == particular ]
Diagrama
de
Estados
Fornece
os
objetos
e
classes
Valida
o
modelo
e
fornece
detalhes
(atributos
e
operações)
146. www.labes.ufpa.br
Diagrama
de
Classes
III.1
Modelagem
de
Dados
III.2
Mapeamento
para
Banco
de
Dados
III.3
Projeto
com
Interfaces
III.4
Diagrama
de
Pacotes
easo5ware,
ufpa,
2015
146
147. www.labes.ufpa.br
Diagrama
de
Classes
• Resumo
– Diagrama
base
para
qualquer
discussão
acerca
da
arquitetura
de
um
sistema
com
UML
easo5ware,
ufpa,
2015
147
148. www.labes.ufpa.br
Diagrama
de
Classes
• Propósito
– Representação
dos
dados
manipulados
e
armazenados
pelos
programas
de
acordo
com
os
conceitos
de
Orientação
a
Objetos
– Notação
fortemente
baseada
no
Diagramas
En9dade-‐
Relacionamento
de
Peter
Chen
easo5ware,
ufpa,
2015
148
149. www.labes.ufpa.br
Diagrama
de
Classes
• Diagrama
de
Classe
– Notação
easo5ware,
ufpa,
2015
149
Nome
da
classe
atributo:
9po
de
dado
atributo:
9po
de
dado
=
valor
inicial
Operação(lista
de
argumentos):
9po
do
resultado
Opcionais
(fornecidos somente após
um melhor entendimento
do sistema)
150. www.labes.ufpa.br
Diagrama
de
Classes
• Aspectos
tratados
pelos
Diagramas
de
Classe:
Dados
e
Funções
easo5ware,
ufpa,
2015
150
Dados
Funções
Eventos
Sistema
Obs:
a
ordem
da
execução
das
funções
(aspecto
temporal)
não
é
tratada
explicitamente
nos
diagramas
de
classe
151. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Permitem
descrever
as
relações
existentes
entre
os
elementos
(objetos)
dos
conjuntos
(classes)
easo5ware,
ufpa,
2015
151
Livros
Pessoas
Autor
de
Escrito
por
152. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
easo5ware,
ufpa,
2015
152
Livro
Pessoa
escrito
por
0..*
1..*
Multiplicidade da associação
Rótulo da associação
153. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Interpretação:
• Um
objeto
de
Livro
está
associado
com
no
mínimog
um
objeto
de
Pessoa,
e
no
máximo
com
uma
quan9dade
indeterminada
• Um
objeto
de
Pessoa
pode
não
estar
vinculado
com
qualquer
objeto
de
Livro
ou
com
uma
quan9dade
indeterminada
easo5ware,
ufpa,
2015
153
Livro
Pessoa
escrito
por
0..*
1..*
154. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Classes:
• Nome
de
“Coisas”
• Rotuladas
no
Singular
– Associações
• Leitura
no
sen9do
“convencional”
(esquerda
para
direita,
de
cima
para
baixo)
easo5ware,
ufpa,
2015
154
155. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
155
Jogador
Gol
0..* +autor0..*
Relação
18..*
0..*
18..*
0..*
Substituição
0..* +substituto0..*
0..*
+substituído
0..*
Expulsão
0..*
+expulso
0..*
Estádio
Arbitro
Torneio
Jogo
0..*0..*
+local
0..*0..*
+principal
2
0..*+auxiliar
2
0..*
1
0..*
+reserva
1
0..*
0..1
1..*
0..1
1..*
HistoriaEquipeJogo
0..*0..*
0..*0..*
0..*0..*
0..*
Equipe
2
0..*
2
0..*
0..*0..*0..*
Exemplo
de
diagrama
conceitual
(9picamente
produzido
nas
primeiras
iterações)
realizado
em
156. www.labes.ufpa.br
Diagrama
de
Classes
• Atributos
easo5ware,
ufpa,
2015
156
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
Obs: Atributos Compostos e
Multivalorados são
permitidos pelo modelo de
dados OO
157. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Observe:
não
há
chave-‐primária
easo5ware,
ufpa,
2015
157
Livro
Título:
Str
ISBN:
Int
Editora:
Str
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
escrito
por
0..*
1..*
Multiplicidade da associação
Rótulo da associação
158. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Papel
de
Classe/Objeto
em
uma
Associação
(em
inglês,
role)
– Pode
ocorrer
simultaneamente
com
o
nome
(rótulo
/
label)
da
associação
– O
papel
é
usado
na
geração
de
código
e
BD
easo5ware,
ufpa,
2015
158
Livro
Título:
Str
ISBN:
Int
Editora:
Str
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
escrito
por
0..*
1..*
autor
obra
Papéis
159. www.labes.ufpa.br
Diagrama
de
Classes
• Atributos
e
Métodos
easo5ware,
ufpa,
2015
159
Conta
Bancária
número
saldo
dataAbertura
criar()
bloquear()
desbloquear()
creditar()
debitar()
Pessoa
Nome:
Str
Endereço:
{
Logradouro:
Str,
Bairro:
Str,
Cidade:
Str.
}
Telefones:
Array
of
Int
1
0..*
9tular
dependente
0..2
0..*
160. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplo
de
Geração
de
Código
em
Java
easo5ware,
ufpa,
2015
160
ContaBancariaPessoa 0..*
1
0..*
1
+titular possui
0..* 0..*+dependente 0..*0..*
Class
ContaBancaria
{
String
numero;
float
saldo;
Date
dataAbertura;
Pessoa
9tular;
Vector
dependente;
}
Omi9dos
do
diagrama
por
simplificação
Os
atributos
que
Implementam
as
Associações
não
devem
Ser
inseridos
no
diagrama
161. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplos:
Associação
Unária
easo5ware,
ufpa,
2015
161
Funcionário
0..1
*
Supervisiona
Funcionário
João
supervisiona
É
supervisionado
por
162. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Exemplos:
Associação
Unária
easo5ware,
ufpa,
2015
162
Funcionário
0..1
*
Supervisiona
Funcionario
0..*
0..1 supervisiona
0..*
0..1+chefe
+subordinado
Evolução:
acréscimo
dos
papéis
facilita
a
implementação
e
o
entendimento
164. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
• Associação
binária
e
bidirecional
easo5ware,
ufpa,
2015
164
Funcionário Departamento
0..* trabalha 1
Funcionário
trabalha
em
Departamento
Funcionário
João
Departamento
Financeiro
165. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
• Associação
binária
e
unidirecional
easo5ware,
ufpa,
2015
165
Funcionário Departamento
0..* trabalha
Funcionário
João
Departamento
Financeiro
166. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Navegabilidade
das
Associações
• Associação
Unidirecional
– Razão
da
existência
è
mais
fácil
a
implementação
easo5ware,
ufpa,
2015
166
168. www.labes.ufpa.br
Diagrama
de
Classes
• Associações
– Mul9plicidade:
limiar inferior..limiar superior
easo5ware,
ufpa,
2015
168
Multiplicidade
Significado
0..1
Zero ou um
1
Somente 1 (opcional)
0..*
Maior ou igual a zero
*
Maior ou igual a zero
1..*
Maior ou igual a 1
1..15 (
m..n)
De 1 a 15 (m a n), inclusive
169. www.labes.ufpa.br
Diagrama
de
Classes
• Exercício:
qual
o
mais
correto?
easo5ware,
ufpa,
2015
169
Funcionário Departamento
1 trabalha 0..1
Funcionário Departamento
0..* trabalha
Funcionário Departamento
0..* trabalha 0..*
(adaptado de BEZ02)
170. www.labes.ufpa.br
Diagrama
de
Classes
• Exemplos
– Funcionário
=
{
João,
Maria,
José
}
– Depto
=
{A,
B}
– Trabalha
=
{
(João,
A),
(Maria,
B),
(José,
B)}
– Gerente
=
{
(João,
B),
(Maria,
A)
}
easo5ware,
ufpa,
2015
170
Funcionário Departamento
trabalha
1*
gerente 0..1
171. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
171
Funcionário
Departamento
Financeiro
TI
João
Marcela
Amanda
Funcionário Departamento
trabalha
1*
gerente 0..1
172. www.labes.ufpa.br
Diagrama
de
Classes
• Exemplo
easo5ware,
ufpa,
2015
172
Financeira
código
nome
Venda
data
hora
Vendedor
número
nenha
nívelAutorização
financia
0..1 * *
realizada por
173. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Informação
que
surge
a
par9r
da
associação
de
duas
outras
classes
– Podem
ser
anônimas
– Um
objeto
de
classe
associa9va
está
associado
com
exatamente
um
objeto
de
cada
extremidade
easo5ware,
ufpa,
2015
173
Fulano,
Cálculo
I,
INS,
75%,
1º
2005
Fulano,
Cálculo
I,
BOM,
100%,
2º
2005
Beltrano,
Mat,
BOM,
90%,
2º
2005
174. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
easo5ware,
ufpa,
2015
174
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Data
Regime
Data
Regime
175. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
175
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
Pessoa
Nome
Endereço: {
Logradouro;
Bairro;
Cidade. }
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
Data
Regime
Data
Regime
Pessoa
João
Marcela
Amanda
Jorge
Abel
dataX
regimeX
dataY
regimeY
176. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
easo5ware,
ufpa,
2015
176
Financeira
código
nome
Venda
data
hora
Vendedor
número
nenha
nívelAutorização
financia
0..1 * *
realizada por
registroAprovação
dataAprovação
Financiamento
177. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Observação
importante:
o
conceito
de
“Classe
Associa9va”
não
é
permi9do
em
todas
as
linguagens
de
programação
e
sistemas
de
banco
de
dados
OO
– Assim,
em
muitos
casos
as
classes
associa9vas
encontradas
em
Análise
são
subs9tuídas
por
classes
regulares
em
Projeto
easo5ware,
ufpa,
2015
177
178. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Classe
associa9va
subs9tuída
por
normal
easo5ware,
ufpa,
2015
178
Obs:
sempre
vai
ser
mul9plicidade
1,
neste
caso
Original
(Análise)
Modificado
(Projeto)
179. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Classe
associa9va
subs9tuída
por
normal
easo5ware,
ufpa,
2015
179
Observar
que
neste
caso
a
subs9tuição
não
é
trivial
visto
que
o
objeto
de
devolução
só
é
criado
após
a
associação
de
Emprés9mo
e
Item.
180. www.labes.ufpa.br
Diagrama
de
Classes
• Classes
associa9vas
– Classe
associa9va
subs9tuída
por
normal
easo5ware,
ufpa,
2015
180
185. www.labes.ufpa.br
Diagrama
de
Classes
• Agregação
– Associa
de
todo/parte
– Ação
realizada
sobre
todo
a9nge
as
partes
– Tipo
especial
de
associação
easo5ware,
ufpa,
2015
185
Documento
Parágrafo
Sentença
0..* 0..*
Documento
Parágrafo
Sentença
0..* 0..*
composto-por composto-por
186. www.labes.ufpa.br
Diagrama
de
Classes
• Agregação
– Exemplo
easo5ware,
ufpa,
2015
186
Associação
Espor9va
Equipe
Jogador
0..* 0..*
◀ afiliada
187. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Todos
os
exemplos
anteriores
envolviam
a
ligação
entre
instâncias
de
classes
(objetos)
– Com
a
Herança,
o
relacionamento
fornecido
é
o
de
subconjunto
– Ú9l
para
definir
hierarquias
de
classes
(não
de
objetos!)
que
possuem
propriedades
comuns
easo5ware,
ufpa,
2015
187
188. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Associação
do
9po
“é
um”
easo5ware,
ufpa,
2015
188
Cliente
nome
PessoaFísica
CPF
RG
Sexo
DataNascimento
PessoaJurídica
CGC
RazãoSocial
Super-classe
Sub-classes
(herdeiras)
189. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Em
Ra9onal
Rose
easo5ware,
ufpa,
2015
189
Cliente
PF
PJ
190. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Polimorfismo
de
dados:
• Uma
associação
pode
ocorrer
com
objetos
de
diferentes
classes
(deste
que
tenham
suas
classes
relacionadas
por
herança).
easo5ware,
ufpa,
2015
190
191. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Polimorfismo
de
dados:
exemplo
• não
há
necessidade
de
se
criar
uma
associação
entre
Compra
e
subclasses
de
Cliente
easo5ware,
ufpa,
2015
191
Cliente
nome
PessoaFísica
CPF
RG
Sexo
DataNascimento
PessoaJurídica
CGC
RazãoSocial
Compra*realiza
193. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Herança
Múl9pla:
caso
especial
easo5ware,
ufpa,
2015
193
Veículo
an„bio
Veículo
Veículo
terrestre
Veículo
aquá9co
Conceito pouco usado na prática:
• Poucas linguagens de programação
permitem o uso
• Adiciona maior complexidade ao
modelo
194. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
– Classe
Abstrata
• Classe
que
não
instancia
objetos.
• Serve
apenas
para
gerar
novas
sub-‐classes
a
par9r
da
herança.
• Freqüentemente
é
uma
classe
ar9ficial,
isto
é,
que
não
existe
no
Domínio
do
Problema
e
surge
para
acomodar
propriedades
comuns
de
classes
concretas.
• Representada
com
‘tulo
em
itálico
ou
com
uma
restrição
{abstrata}
(ou
{abstract})
easo5ware,
ufpa,
2015
194
195. www.labes.ufpa.br
Diagrama
de
Classes
• Generalização/Especialização
easo5ware,
ufpa,
2015
195
Cliente
ContaBancária
número
dataAbertura
saldo
debitar(quantia)
creditar(quantia)
Transação
ContaCorrente
limiteSaque
ContaPoupança
dataAniversário
* *
Classe
Abstrata
possui
199. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
– São
regras
especificadas
com
lógica
ou
com
linguagem
específica
(*)
para
impedir
/
condicionar
a
criação
de
objetos
e
associações
– Úteis
para
especificar
regras
de
negócios
no
diagrama
– (*)
Object
Constrain
Language
-‐
OCL
easo5ware,
ufpa,
2015
199
200. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
–
Exemplo
{ou}
– Restrição
{ou}
implica
na
seleção
exclusiva
entre
duas
ou
mais
associações
existentes
em
uma
classe
easo5ware,
ufpa,
2015
200
Conta
corrente
Indivíduo
Organização
0..*
0..*
0..1
0..1
{ou}
cliente
cliente
201. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
201
Conta
corrente
Cliente
Organização
0..*
0..1
cliente
Indivíduo
Conta
corrente
Indivíduo
Organização
0..*
0..*
0..1
0..1
{ou}
cliente
cliente
Obs:
são
equivalentes
Notar
classe
abstrata
202. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
202
Contrato
de
Seguro
Indivíduo
Empresa
0..*
0..*
1..*
1..*
{ou}
Contrato
Cliente
Organização
0..*
1..*
Indivíduo
OBS:
Não
são
equivalentes!
Por
que?
203. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
203
Significado:
seja
uma
pessoa
(empregado),
seu
empregador
é
mesmo
do
seu
chefe
204. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
– Restrição
{subconjunto}
ou
{subset}
• Estabelece
relação
de
subconjunto
entre
duas
associações
easo5ware,
ufpa,
2015
204
Pessoa
Comitê
Membro-‐de
Presidente-‐de
{subconjunto}
0..*
0..*
0..*
205. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
205
Pessoa
Comitê
Membro-‐de
Presidente-‐de
{subconjunto}
0..*
0..*
0..*
Pessoa
=
{joão,
josé,
maria}
Comitê
=
{
é9ca,
licitações
}
Membro-‐de
=
{
(joão,
é9ca),
(josé,
licitações),
(maria,
licitações),
(maria,
é9ca)
}
Opções
(A)
Presidente-‐de
=
{(joão,
é9ca),
(maria,
licitações)}
(B)
Presidente-‐de
=
{(maria,
licitações),
(maria,
é9ca)}
(C)
Presidente-‐de
=
{(josé,
é9ca)}
(errado,
não
é
subconjunto
de
Membro-‐de)
(D)
Presidente-‐de
=
{(maria,
licitações)}
(errado,
pois
cada
comitê
deve
possuir
um
presidente
–
e,
no
caso,
é9ca
não
tem
presidente)
206. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
206
Funcionário Departamento
trabalha 1*
gerente 0..1
{subconjunto}
Funcionário
=
{
rodrigo,
carla,
dio
}
Departamento
=
{
informá9ca,
administração
}
(A) Trabalha
=
{
(rodrigo,
informá9ca),
(dio,
administração),
(carla,
informá9ca)
}
Gerente
=
{
(rodrigo,
informá9ca)
}
[errado,
pois
o
departamento
de
administração
não
possui
gerente]
(B)
Trabalha
=
{
(rodrigo,
informá9ca),
(dio,
administração)
,
(carla,
administração)
}
Gerente
=
{
(dio,
informá9ca)
,
(dio,
administração)
}
207. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
207
Empregado
salário
chefe
{Empregado.salário
<
Empregado.chefe.salário}
Janela
comprimento
largura
{0,8<=comprimento/largura<=1,5}
Cargo
prioridade
{prioridade
nunca
cresce}
1..*
1
Janela
Tela
Visível
em
{ordenado}
*
208. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
208
Pessoa
Nome
Endereço:
{
Logradouro;
Bairro;
Cidade.
}
Sexo
marido
esposa
0..1
0..1
casamento
Data
Regime
{pessoa.sexo=Feminino}
{pessoa.sexo=Masculino}
209. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições:
exemplos
diversos
easo5ware,
ufpa,
2015
209
Pessoa
Nome
Endereço:
{
Logradouro;
Bairro;
Cidade.
}
Sexo
cônjuge
0..1
0..1
casamento
Data
Regime
{pessoa.sexo
<>
pessoa.cônjuge.sexo}
211. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
211
Pessoa
=
{
joão,
maria,
márcio,
fulano,
beltrano}
Condomínio
=
{
Greenville
I,
Greenville
II,
Costa
e
Silva
}
condômino
=
{
(joão,
greenville
I),
(maria,
greenville
II),
(márcio,
greenville
II),
(fulano,
costa
e
silva),
(beltrano,
costa
e
silva)
}
Síndico
=
{
(joão,
greenville
I),
(márcio,
greenville
II),
(fulano,
costa
e
silva)
}
Pessoa Condomínio
condômino
síndico
*
{subconjunto}
0..1
212. www.labes.ufpa.br
Diagrama
de
Classes
• Restrições
easo5ware,
ufpa,
2015
212
Conta
Bancária
número
saldo
dataAbertura
criar()
bloquear()
desbloquear()
creditar()
debitar()
Pessoa
nome:
Str
endereço:
{
logradouro:
Str,
bairro:
Str,
cidade:
Str.
}
telefones:
Array
of
Int
1..*
*
corren9sta
9tular
{subconjunto}
*
213. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
213
Conta
Bancária
número
saldo
dataAbertura
Pessoa
nome:
Str
endereço:
{
logradouro:
Str,
bairro:
Str,
cidade:
Str.
}
telefones:
Array
of
Int
1..*
*
corren9sta
9tular
{subconjunto}
*
Conta
Bancária
=
{
001,
002,
003
}
Pessoa
=
{rodrigo,
carla,
fulana
}
Corren9sta
=
{
(001,
carla),
(002,
rodrigo),
(001,
rodrigo)
(001,
fulana)
(003,
fulana)
(003,
rodrigo}
Titular
=
{
(001,
rodrigo),
(002,
rodrigo)
,
(003,
rodrigo),
(001,
carla)
}
214. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
214
Conta
Corrente
número
saldo
dataAbertura
PessoaJurídica
nome:
Str
1..*
*
corren9sta
9tular
{subconjunto}
*
1
PessoaFísica
Representante
1..*
*
215. www.labes.ufpa.br
Diagrama
de
Classes
easo5ware,
ufpa,
2015
215
Aluno
Turma
1..*
representante
*
{subconjunto}
Exemplo
válido:
Aluno
=
{
amanda
,
breno
}
Turma
=
{01,
02}
Representante
=
{
(amanda,
01),
(amanda,
02)
}
Membro
=
{
(amandav,
01),
(amanda,
02),
(breno,
01)
}
1..*
216. www.labes.ufpa.br
Diagrama
de
Classes
• Transmutação
ou
Metamorfose
de
Objetos
– Monitor,
Professor,
Aluno:
herança
easo5ware,
ufpa,
2015
216
Pessoa
AlunoProfessor
Monitor
217. www.labes.ufpa.br
Diagrama
de
Classes
• Transmutação
ou
Metamorfose
de
Objetos
– Monitor,
Professor,
Aluno:
herança
• Problemas
– Acomodação
inábil
de
objetos
que
mudam
de
classes
easo5ware,
ufpa,
2015
217
Pessoa
AlunoProfessor
Monitor