Análise e Projeto de Software Parte II. Marcos Dósea
|
|
- Luzia do Amaral Zagalo
- 6 Há anos
- Visualizações:
Transcrição
1 Análise e Projeto de Software Parte II Marcos Dósea marcosdosea@gmail.com
2 Agenda Aula III Análise de Software Orientado à Objetos
3 Motivação Marcos Dósea
4 O que é análise e projeto?
5 Qual a importância?
6 Por onde começar? Visão do Sistema Modelagem de Negócio Requisitos Análise Projeto Implementação
7 Análise de Software Orientada a Objetos Marcos Dósea marcosdosea@gmail.com
8 Agenda Introdução Analisar Caso de Uso
9 Onde estamos? Introdução
10 Introdução Análise x Projeto Análise Foco no problema Comportamento caixa preta Estrutura geral da arquitetura do sistema Requisitos Funcionais Modelo simples Projeto Foco na solução Detalha operações e atributos dos objetos Representação próxima do código. Requisitos Funcionais e Não Funcionais Modelo complexo.
11 Introdução O que faremos? Análisar o Software
12 Introdução Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados
13 Analisar Caso de Uso 1) Identificar as Classes de Análise 2) Identificar Persistência 3) Identificar Responsabilidades das Classes 4) Identificar Atributos e Relacionamentos
14 1) Identificar as Classes de Análise Para cada Caso de Uso são identificadas os três tipos de classe de análise: Fronteira: modela iteração entre ator e sistema. Entidade: Modela a informação manipulada pelo sistema. Conceito análogo ao modelo ER. Controle: Controla o fluxo de execução do caso de uso.
15 1) Identificar as Classes de Exemplo Análise
16 1) Identificar as Classes de Análise Como encontrar? Classes de Fronteira? Classes de Controle? Classes de Entidade?
17 1) Identificar as Classes de Análise Classes de Fronteira Regra: Uma classe para cada interação entre ator e um caso de uso. Devolver Livro Usuário TelaDevolverLivro
18 1) Identificar as Classes de Classe de Controle Análise Regra: Uma classe de controle para cada caso de uso. Quando muito simples pode-se utilizar uma única classe de controle para vários casos de uso. Outra possibilidade é usar uma classe de controle por entidade manipulada.
19 1) Identificar as Classes de Classe de Controle Análise Devolver Livro Usuário ou ou ControladorDevolucao ControladorBiblioteca ControladorLivro
20 1) Identificar as Classes de Classe de Entidade Análise Regra: Abordagem tradicional de filtrar substantivos. Ex: Objetos Físicos ou tangíveis, Lugares, Papéis de Pessoas, Eventos, etc. Balconista Livro Usuario Emprestimo
21 1) Identificar as Classes de Análise Classe de Entidade Passo a Passo Identifique substantivos nas fontes de informação (modelo de negócio, casos de uso, glossário, etc.). Remova candidatos redundantes e vagos. Remova atores que apenas interagem com o sistema mas não participam da modelagem. Remova atributos (serão pensados mais tarde) e operações (devem ficar na classe controladora).
22 Analisar Caso de Uso 1) Identificar as Classes de Análise 2) Identificar Persistência 3) Identificar Responsabilidades das Classes 4) Identificar Atributos e Relacionamentos
23 2) Identificar Persistência Identifica entre as classe de análise do tipo entidade aquelas que deverão ser persistidas. Classes persistentes são aquelas cujos atributos devem ser armazenados em meio não volátil (Ex: SGBD). Para cada classes persistente criar uma classe de cadastro usando o esteriótipo <<entity collection>>
24 2) Identificar Persistência Classes de Entidade Persistentes Livro Usuario Balconista Emprestimo <<entity collection>> CadastroLivros <<entity collection>> CadastroUsuarios <<entity collection>> CadastroBalconistas <<entity collection>> CadastroEmprestimos
25 Analisar Caso de Uso 1) Identificar as Classes de Análise 2) Identificar Persistência 3) Identificar Responsabilidades das Classes 4) Identificar Atributos e Relacionamentos
26 3) Identificar Responsabilidades das Classes Os diagramas de sequência e comunicação devem ser utilizados nessa fase para identificação das responsabilidades das classes. Cada caso de uso analisado adiciona novos comportamentos as classes. Cada caso de uso pode gerar um ou mais diagramas de sequência.
27 3) Identificar Responsabilidades das Classes
28 3) Identificar Responsabilidades das Classes Métodos identificados Importante utilizar boas ferramentas de modelagem para automatizar o processo. Emprestimo <<entity collection>> CadastroEmprestimos +buscaremprestimo() +atualizaemprestimo() <<<boundary>>> TelaDevolverLivro +devolverlivro()
29 Analisar Caso de Uso 1) Identificar as Classes de Análise 2) Identificar Persistência 3) Identificar Responsabilidades das Classes 4) Identificar Atributos e Relacionamentos
30 4) Identificar Atributos e Relacionamentos Onde encontrar os atributos e relacionamentos? Modelo de negócio Requisitos de Usuário e de Sistema Glossário etc.
31 4) Identificar Atributos e Relacionamentos As classes identificadas não funcionam sem relacionar-se com as outras. Os diagramas de sequência e comunicação são muito úteis nessa tarefa. Para cada ligação nesses diagramas deve ser gerado um relacionamento.
32 4) Identificar Atributos e Exemplo: Relacionamentos A ligação indica que existe um relacionamento entre a classe ControladorDevolucao e a classe CadastroEmprestimo
33 4) Identificar Atributos e Relacionamentos Relacionamentos Identificados <<entity>> Livro <<<boundary>>> TelaDevolverLivro <<entity>> Emprestimo possui * * +devolverlivro(emprestimo: Emprestimo) é realizado * 1 * 1 <<entity>> Balconista 1 * <<control>> ControladorDevolucao <<entity collection>> CadastroEmprestimos +buscaremprestimo(emprestimo: Emprestimo) +devolverlivro(emprestimo: Emprestimo) +calculamultaporatraso(emprestimo: Emprestimo) 1 1 +buscar(emprestimo: Emprestimo) +atualizar(emprestimo: Emprestimo)
34 4) Identificar Atributos e Relacionamentos Atributos Identificados <<<boundary>>> TelaDevolverLivro +devolverlivro(emprestimo: Emprestimo) * <<entity>> Emprestimo 1 possui * * é realizado * 1 <<entity>> Livro +isbn +nome <<entity>> Balconista 1 * +cpf +nome <<control>> ControladorDevolucao <<entity collection>> CadastroEmprestimos +buscaremprestimo(emprestimo: Emprestimo) +devolverlivro(emprestimo: Emprestimo) +calculamultaporatraso(emprestimo: Emprestimo) 1 1 +buscar(emprestimo: Emprestimo) +atualizar(emprestimo: Emprestimo)
35 Em resumo Glossário Documento da arquitetura Classes de Análise (detalhada) Documento de requisitos Analisar caso de uso Realização de caso de uso (atualizada) Modelo de caso de uso Modelo de Análise
36 Próximos passos Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados
37 Atividade Sala III Crie o modelo de análise para o Caso de Uso Emprestar Livro
38 Agenda Aula IV Projetar Arquitetura Projeto do Software
39 Projetar Arquitetura Marcos Dósea
40 Agenda Introdução Projetar Arquitetura
41 Onde estamos? Introdução
42 Introdução O que faremos? Projetar Arquitetura
43 Introdução Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados
44 Projetar Arquitetura Avaliar o conjunto das classes de análise. Definir elementos de projeto (classes de projeto e subsistemas) e organizá-los em pacotes. Definir a estrutura da aplicação para os projetistas possam detalhar a aplicação nas próximas fases.
45 Projetar Arquitetura 1) Definir o mapeamento entre as classes de análise e os elementos de projeto 2) Identificar subsistemas 3) Identificar oportunidades de Reuso 4) Definir a estrutura da aplicação
46 1) Definir o mapeamento entre as classes de análise e os elementos de projeto Para cada classe de análise deve-se definir se ela dará origem a: Uma classe de projeto. Mais de uma classe de projeto. Um subsistema Zero classes de projeto, ela será incorporada a uma outra classe de projeto já existente. A definição do mapeamento é muito dependente da experiência do arquiteto e do estilo arquitetural escolhido.
47 1) Definir o mapeamento entre as classes de análise e os elementos de projeto Algumas sugestões para definição Sugestão 1) 1 classe de análise é mapeada para 1 classe de projeto se ela for simples e representar uma única abstração. Sugestão 2) Classes de análises muito simples devem ser combinada em uma única classe de projeto. Sugestão 3) Classes de análises muito complexas devem ser quebradas em classes mais simples ou gerar um subsistema.
48 1) Definir o mapeamento entre as classes de análise e os elementos de projeto Algumas sugestões para definição Sugestão 4) Toda classe de entidade gera uma classe de projeto excluindo o esteriótipo.
49 1) Definir o mapeamento entre as classes de análise e os elementos de projeto Exemplos: <<<boundary>>> TelaDevolverLivro +devolverlivro() ITela TelaDevolverLivro +processa() Para cada classe de fronteira identificada que for uma tela de interação com o usuário deve-se criar uma classe com o mesmo nome que implementa a interface ITela. Essa classe deve conter apenas o método processa() que obtém os dados da interface e realiza a próxima operação.
50 1) Definir o mapeamento entre as classes de análise e os elementos de projeto Exemplos: <<entity>> Livro +isbn +nome Livro +isbn +nome Para cada classe de entidade identificada deve existir uma classe de projeto correspondente sem o esteriótipo.
51 1) Definir o mapeamento entre as classes de análise e os elementos de projeto Exemplos: <<control>> ControladorEmprestimo +emprestarlivro() <<control>> ControladorDevolucao +buscaremprestimo() +devolverlivro() +calculamultaporatraso() ControladorLivro +buscaremprestimo() +devolverlivro() +calcularmultaatraso() +emprestarlivro() IControladorLivro Classes de controle que manipulem uma mesma entidade devem ser unidas em uma única classe que implementa uma interface de projeto que vai unir as interfaces dessas classes de análise. O nome da classe de projeto e da interface criada deve referenciar a entidade que ela manipula.
52 Projetar Arquitetura 1) Definir o mapeamento entre as classes de análise e os elementos de projeto 2) Identificar subsistemas 3) Identificar oportunidades de Reuso 4) Definir a estrutura da aplicação
53 2) Identificar Subsistemas O que é um subsistema? O subsistema divide o sistema em partes independentes (componentes) que possuem uma interface bem definida e que pode ser desenvolvido, testado e implantado de forma independente dos demais.
54 2) Identificar Subsistemas O que é um subsistema? Cada subsistema deve possuir uma classe fachada que implementa a sua interface. Subsistema FachadaSubsistema ISubsistema
55 2) Identificar Subsistemas Como identificar subsistemas? Experiência do arquiteto conta muito. Algumas regras que podem ajudar: Sugestão 1) Classes de análise fronteira que fazem interface com outros sistemas são normalmente candidatos a serem subsistemas. <<boundary>> ComunicacaoEditora +atualizarlivro(isbn: long) ComunicacaoEditora Fachada IComunicacaoEditora +atualizarlivro(isbn: String)
56 2) Identificar Subsistemas Como identificar subsistemas? Sugestão 2) Classes que fornecem serviços complexos. Sugestão 3) Classes utilitárias e que dão suporte ao acesso ao banco de dados. Sugestão 4) Classes reusáveis autocontidas como softwares de comunicação, estruturas de dados, etc. ComunicacaoCatraca Fachada IComunicacaoCatraca +registraentrada(matricula: String) +registrasaida(matricula: String)
57 Projetar Arquitetura 1) Definir o mapeamento entre as classes de análise e os elementos de projeto 2) Identificar subsistemas 3) Identificar oportunidades de Reuso 4) Definir a estrutura da aplicação
58 3) Identificar Oportunidades de Reuso Verifica se um subsistema pode ser comprado ou reutilizado, ao invés de desenvolvido. Ex: Subsistema da catraca e utilitários. Deve-se analisar o impacto de mudar a interface do subsistema para adaptá-la à necessidade do novo sistema. Deve-se também avaliar a possibilidade de modificar um subsistema existente de forma a torná-lo reutilizável.
59 Projetar Arquitetura 1) Definir o mapeamento entre as classes de análise e os elementos de projeto 2) Identificar subsistemas 3) Identificar oportunidades de Reuso 4) Definir a estrutura da aplicação
60 4) Definir a Estrutura da Aplicação O arquiteto define o estilo arquitetural que será adotado, os padrões de projeto e idiomas. Essas definições devem estar registradas no documento de arquitetura. O documento de arquitetura é normalmente padrão para todos os sistemas de organização mas deve ser atualizado a cada necessidade de sistema. As regras de mapeamento devem ser atualizadas para adptar-se à estrutura da aplicação escolhida.
61 4) Definir a Estrutura da Aplicação Exemplo: Biblioteca Estilo Arquitetural: Camadas (Layer) Padrões de Projeto: Façade (Fachada): Para abstrair a camada de negócio. Singleton: Apenas uma instância para cada objeto responsável pela pela persistência dos dados.
62 4) Definir a Estrutura da Aplicação Exemplo: Biblioteca Estilo Arquitetural: Camadas (Layer) Interface com o usuário (GUI) Negócio Dados
63 4) Definir a Estrutura da Aplicação Por usar o estilo em camadas? Mudanças em uma camada não afeta as camadas adjascentes, desde que as interfaces sejam preservadas. Uma mesma versão da camada trabalhando com diferentes versões de outra camadas. Ex: Diferentes interfaces gráficas Diferentes forma de acesso a dados.
64 4) Definir a Estrutura da Aplicação No nosso exemplo da biblioteca temos: Camada GUI: Responsável por obter os dados da interface e invocar um método de negócio Camada de Negócio: Contém toda lógica de negócio da aplicação e caso necessário chama a camada de acesso a dados. Camada de Dados: Contém toda lógica necessária para acessar um meio persistente.
65 4) Definir a Estrutura da Aplicação Exemplo: Criando a Camada GUI <<<boundary>>> TelaDevolverLivro +devolverlivro() ITela TelaDevolverLivro +processa() Análise Projeto Interface com o usuário (GUI)
66 4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? Define uma forma padrão para processar os dados provenientes da interface.
67 4) Definir a Estrutura da Aplicação Exemplo: Criando a Camada Negocio <<control>> ControladorEmprestimo Fachada IFachada +emprestarlivro() <<control>> ControladorDevolucao ControladorLivro IControladorLivro +buscaremprestimo() +devolverlivro() +calcularmultaatraso() +emprestarlivro() +buscaremprestimo() +devolverlivro() +calculamultaporatraso() +buscaremprestimo() +devolverlivro() +calcularmultaatraso() +emprestarlivro() Análise Projeto Negócio
68 4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? A Fachada oferecer uma interface única para um conjunto de interfaces de um subsistema. Minimiza a dependência entre os subsistemas. Facilidade para os clientes da camada de negócio que precisam conhecer apenas uma única classe.
69 4) Definir a Estrutura da Aplicação Exemplo: Criando a Camada de Dados <<entity collection>> CadastroEmprestimos +buscar() +atualizar() RepositorioEmprestimoBDR +getinstance() Emprestimo * 1 <<entity>> Emprestimo IRepositorioEmprestimo +buscar() +atualizar() +inserir() Análise Projeto Dados
70 4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? RepositorioEmprestimoBDR +getinstance() RepositorioEmprestimoBDOO IRepositorioEmprestimo +getinstance() +buscar() +atualizar() +inserir() RepositorioEmprestimoFile +getinstance()
71 4) Definir a Estrutura da Aplicação Por que utilizar essa estrutura? O padrão singleton: Usado porque é desnecessário existirem várias instâncias de classes para acessar o banco de dados. Melhor utilização da memória. Define como acessar de forma controlada uma única instância da classe. Permite facilmente variar o número de instâncias caso seja necessário.
72 4) Definir a Estrutura da Aplicação TelaDevolverLivro GUI ITela +processa() Negocio Fachada IFachada ControladorLivro ControladorAluno IControladorLivro IControladorAluno Dados RepositorioEmprestimoBDR IRepositorioEmprestimo +getinstance()
73 Em Resumo Modelo de casos de uso Mapeamento das classes de análise em elementos de projeto Documento de requisitos Projetar Arquitetura Documento da arquitetura Modelo de análise e projeto (classes de análise) Modelo de análise e projeto (classes de projeto e subsistemas)
74 Próximos passos Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados
75 Projeto de Software Orientada a Objetos Marcos Dósea marcosdosea@gmail.com
76 Agenda Introdução Projetar Caso de Uso
77 Onde estamos? Introdução
78 Introdução Análise x Projeto Análise Foco no problema Comportamento caixa preta Estrutura geral da arquitetura do sistema Requisitos Funcionais Modelo simples Projeto Foco na solução Detalha operações e atributos dos objetos Representação próxima do código. Requisitos Funcionais e Não Funcionais Modelo complexo.
79 Introdução O que faremos? Projetar o Software
80 Fluxo de Análise e Projeto Arquiteto Projetar arquitetura Revisor do projeto Projetar subsistema Projetista Analisar caso de uso Projetar caso de uso Projetar classes Revisar projeto Projetista de banco de dados Projetar base de dados
81 Projetar Caso de Uso Refinar as realizações de casos de uso substituindo os elementos de análise (elaboradas na análise de casos de uso) por elementos de projeto definido no mapeamento projeto da arquitetura. Incorporar persistência nas realizações O modelo final serve de referência para a implementação do caso de uso
82 Projetar Caso de Uso 1) Refinar as realizações de casos de uso 2) Simplificar os diagramas de interação.
83 1) Refinar as Realizações de Caso de Uso Substitui as classes de projeto e ou interfaces dos subsistemas associados seguindo as recomendações da arquitetura. Incorporar a persistência Atualizar os diagramas que realizam o caso de uso: Diagramas de interação Diagramas de Classes
84 1) Refinar as Realizações de Caso de Uso Como era a análise? <<boundary>> : TelaDevolverLivro <<control>> : ControladorDevolucao <<entity collection>> : CadastroEmprestimos : Balconista 1 : devolverlivro() <<create>> 2 <<entity>> : Emprestimo 4 : devolverlivro() 3 5 : buscar() 6 7 : calculamultaporatraso() 8 : atualizar() 11 : resultado() 10 9
85 1) Refinar as Realizações de Caso de Uso Como era na análise?
86 1) Refinar as Realizações de Caso de Uso Como ficou no projeto? Para projetar as classes deve-se obedecer as regras de mapeamento entre classes de análise e classe de projeto definidas pelo arquiteto. Para cada diagrama de interação de análise deve ser criado um diagrama de interação com as classes de projeto. É recomendado também criar o diagrama de classes de projeto que realizam o caso de uso.
87 Lembrando a Arquitetura TelaDevolverLivro GUI ITela +processa() Negocio Fachada IFachada ControladorLivro ControladorAluno IControladorLivro IControladorAluno Dados RepositorioEmprestimoBDR IRepositorioEmprestimo +getinstance()
88 1) Refinar as Realizações de Caso de Uso Como ficou no projeto?
89 1) Refinar as Realizações de Caso de Uso Como ficou no projeto?
90 2) Simplificar os diagramas de interação Identifique subfluxos comuns nos diagramas de interação e encapsule-os em subsistemas (possivelmente novos) Substitua os elementos internos pela interface dos subsistemas (nos diagramas) Interações internas ao subsistema serão descritas na atividade Projetar subsistema
91 2) Simplificar os diagramas de interação Quando encapsular fluxos em subsistemas? Quando um subfluxo: ocorre em vários casos de uso possui potencial de reuso é complexo e de fácil encapsulamento é responsabilidade de uma equipe/pessoa específica produz um resultado bem definido é encapsulado dentro de um componente de implementação É importante nessa etapa estabilizar a interface.
92 Projetar Caso de Uso Documento de requisitos Subsistemas de projeto Realização de caso de uso Projetar Caso de Uso Realização de caso de uso Caso de uso Classes de projeto
93 Atividade Sala IV Criar o modelo de projeto para o Caso de Uso Emprestar Livro.
94 Projeto da Disciplina 1) Criar o modelo de análise para o estudo de caso proposto, ou seja, para cada caso de uso identificado, apresentar os diagramas de interação e o diagrama de classes que o realizam. Crie um documento único que agrupe os vários modelos de análise criados.
95 Projeto da Disciplina 2) Definir (i) arquitetura do sistema do projeto proposto e (ii) as regras de mapeamento para os elementos de projeto. Utilize o template do RUP para documentação desses dois documentos.
96 Projeto da Disciplina 3) Crie o modelo de projeto de software utilizando as regras de mapeamento definidas pelo arquiteto. Crie um documento único que agrupe os vários modelos de projeto criados.
97 Projeto da Disciplina Em resumo... (1) Documento com Modelos de Análise (2) Documento da Arquitetura (3) Documento com Mapeamentos entre Modelos de Análise e Projeto (4) Documento com Modelos de Projeto
Realizando a Análise e Projeto
Realizando a Análise e Projeto Modelagem de Negócios O que temos: Modelagem dos processos: Diagrama de Atividades Modelo de Casos de Uso de Negócio: Modelo de Objetos de Negócio Ator de negócio, trabalhador
Leia maisEngenharia de Software Orientada a objetos. Prof. Rogério Celestino dos Santos
Engenharia de Software Orientada a objetos Prof. Rogério Celestino dos Santos http://sites.google.com/site/rogeriocsaulas/ Estereótipos são uma maneira de destacar determinados componentes do diagrama,
Leia maisRequisitos de sistemas
Requisitos de sistemas Unidade III - Casos de Uso Identificação de casos de uso Conceitos de orientação a objetos Modelagem do diagrama de classes e casos de uso 1 Casos de uso CONCEITO Especifica o comportamento
Leia maisInterações entre objetos
Interações entre objetos 1 Interações! Interações mostram os aspectos dinâmicos de um sistema, enfatizando a troca de mensagens entre objetos! Dois diagramas podem ser usados para modelar as interações:
Leia maisAnalisar Caso de Uso
Analisar Caso de Uso Objetivos deste módulo Apresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatos Apresentar os diagramas de seqüência, colaboração
Leia maisAnálise Orientada a Objetos. Análise e Projeto
Análise Orientada a Objetos Análise e Projeto Análise versus Projeto Foco no entendimento do problema Projeto idealizado Comportamento Estrutura do sistema Requisitos funcionais Modelos simples Foco no
Leia maisIntrodução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.
Diagramas UML Classe, Seqüência e Atividades Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 15 de maio
Leia maisAnálise e Projeto de Software Parte I. Marcos Dósea
Análise e Projeto de Software Parte I Marcos Dósea marcosdosea@gmail.com Agenda Apresentação do professor Apresentação da disciplina Metodologia e avaliação Apresentação do professor Marcos Barbosa Dósea
Leia maisDesenvolvimento 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 2006 Profa. Dra. Itana Gimenes RUP: Projeto Artefatos Modelo de Projeto: Lista de classes de
Leia maisPROJETO DE ARQUITETURA
PROJETO DE ARQUITETURA Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Próximas aulas: Seminários de Padrões de Projeto GoF 1º Dia: 10/11/2017, 08h 10h, Sala 04 2º Dia:
Leia maisDiagrama de Classes. Régis Patrick Silva Simão. Régis Simão Diagrama de Classes 1/42
Diagrama de Classes Régis Patrick Silva Simão Régis Simão Diagrama de Classes 1/42 Agenda Introdução Objetos Classes Atributos Operações & Métodos Relacionamentos Relacionamento: Associação Nome de Relacionamento
Leia maisPCS3413 Engenharia de Software e Banco de Dados
PCS3413 Engenharia de Software e Banco de Dados Aula 23 Escola Politécnica da Universidade de São Paulo 1 Acoplamento! Indica dependência entre classes.! Deve ser o menor possível.! Direcionar associações
Leia maisPROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001
PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO Projeto de Programas PPR0001 QUALIDADE DO PROJETO 2 3 Qualidade do Projeto de Software Modularidade: gerar particionamento em elementos que executam funções
Leia maisAnálise e Projeto em SOA (Service Oriented Architecture)
Análise e Projeto em SOA (Service Oriented Architecture) Análise e Projeto em SOA (Service Oriented Architecture) Requisitos Modelagem do Negócio Planejamento Especificação do modelo de negócios Analisar
Leia maisVisões Arquiteturais. Visões Arquiteturais
Visões Arquiteturais Separar diferentes aspectos em visões separadas com o objetivo de gerenciar complexidade. Cada visão descreve diferentes conceitos da Engenharia. Visões permitem reduzir a quantidade
Leia mais15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos
DCC / ICEx / UFMG Pensar Orientado a Objetos Projeto Orientado a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Onde quer que você olhe no mundo real, você vê objetos Pessoas, animais, plantas,
Leia maisModelos. Banco de dados. Professor: Jarbas Araújo CENTRO EDUCACIONAL RADIER.
Modelos Banco de dados Professor: Jarbas Araújo professorjarbasaraujo@gmail.com CENTRO EDUCACIONAL RADIER Projeto de banco de dados Todo bom sistema de banco de dados deve apresentar um projeto, que visa
Leia maisDMS - DOCUMENTO DE MODELAGEM DE SISTEMA VERSÃO: [NOME DO SISTEMA] [SIGLA] [AUTORES]
DMS - DOCUMENTO DE MODELAGEM DE SISTEMA Este documento foi criado seguindo as recomendações e orientações do livro UML na Prática Do Problema ao Sistema e do modelo PRISM do MPDS (Modelo Prático para Desenvolvimento
Leia maisModelagem Orientada a Objetos
DCC / ICEx / UFMG Modelagem Orientada a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Atividades de Modelagem OO 1. Definir o contexto do sistema 2. Projetar a arquitetura 3. Identificar
Leia maisAnálise e Projeto no RUP
Análise e Projeto no RUP Contexto Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso em mãos. Queremos agora gerar um primeiro modelo do sistema a partir dos casos
Leia maisAnálise e Projeto no RUP
Análise e Projeto no RUP Contexto Após a análise de requisitos, temos documentos de requisitos e os casos de uso em mãos. Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso (requisitos
Leia maisRUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN
RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS Prof. Fabiano Papaiz IFRN O RUP recomenda as seguintes práticas que devem ser utilizadas no desenvolvimento de um software: 1. Desenvolver de forma iterativa
Leia mais4 Processo de Transformação
Tecnologias Relacionadas 43 4 Processo de Transformação Com a constante mudança nos requisitos (funcionais e não funcionais) do domínio da aplicação, há uma grande necessidade de que os sistemas estejam
Leia maisPROJETO DE DESENVOLVIMENTO DE SOFTWARE
PROJETO DE DESENVOLVIMENTO DE SOFTWARE Professor: Diego Oliveira Aula 12: Diagrama de Classes Diagrama de Classes Seu principal objetivo é permitir a visualização das classes que vão compor o sistema,
Leia maisIntrodução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos
Introdução Laboratório de Computação para Ciências Módulo II Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Mestrado Profissional
Leia maisVisões Arquiteturais. Arquitetura de Software Thaís Batista
Visões Arquiteturais Separar diferentes aspectos em visões separadas com o objetivo de gerenciar complexidade. Cada visão descreve diferentes conceitos da Engenharia. Visões permitem reduzir a quantidade
Leia maisLevantamento de classes (Análise de casos de uso)
Plano Levantamento de classes (Análise de casos de uso) Prof. Cesar Augusto Tacla Levantamento no método APOO Projeto por padrões: MVC e Observador Estereótipos de classes Visão geral do método Engenharia
Leia maisIntrodução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos
Conceitos Básicos Introdução Tópicos Especiais Modelagem de Dados Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Mestrado Profissional
Leia maisFerramenta MVCASE - Estágio Atual: Especificação, Projeto e Construção de Componentes
Ferramenta MVCASE - Estágio Atual: Especificação, Projeto e Construção de Componentes Antônio Francisco do Prado Daniel Lucrédio e-mail: prado@dc.ufscar.br Resumo Este artigo apresenta a ferramenta CASE
Leia maisModelagem de Casos de Uso (Parte 1)
Modelagem de Casos de Uso (Parte 1) Introdução (1) Objetivos Principais dos Casos de Uso: Delimitação do contexto de um sistema Documentação e o entendimento dos requisitos Descrição dos requisitos funcionais
Leia maisDesenvolvimento de Aplicações Desktop
Desenvolvimento de Aplicações Desktop Conceitos Básicos de POO Professor: Charles Leite Motivação Na Programação OO, um OBJETO é considerado a entidade central de um programa Assim, o desenvolvimento de
Leia maisTarciane Andrade. tarcianeandrade@gmail.com
Tarciane Andrade tarcianeandrade@gmail.com Contexto Análise Passando de casos de uso para diagramas de classes 2 Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso
Leia maisMER e DER Entidades Relacionamentos Atributos Ferramentas CASE Exemplos de DERs Exemplo de Minimundo. Banco de Dados. Aula 1.
Banco de Dados Aula 1.5 - Modelo ER Bruno Neiva Moreno Instituto Federal do Rio Grande do Norte Campus Nova Cruz bruno.moreno@ifrn.edu.br 1/40 Modelo Entidade Relacionamento Descreve objetos (entidades),
Leia maisAgenda da Aula. Arquitetura de Software e Padrões Arquiteturais. Elementos de um Padrão. Arquitetura de Software. Arquitetura de Software
Reuso de Software Aula 04 Agenda da Aula Arquitetura de Software e Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com 14 Março 2012 Arquitetura de Software Padrões arquiteturais
Leia maisTécnicas de Identificação
Técnicas de Identificação Várias técnicas (de uso não exclusivo) são usadas para identificar classes: 1. Categorias de Conceitos 2. Análise Textual de Abbott (Abbot Textual Analysis) 3. Análise de Casos
Leia maisEngenharia de Domínio e Desenvolvimento Baseado em Componentes. Processo DBC-Arch-DE Apoio do Ambiente Odyssey no Processo Considerações Finais
Um Processo de Engenharia de Domínio com foco no Projeto Arquitetural Baseado em Componentes Ana Paula Blois Cláudia Werner Karin Becker Agenda Motivação Engenharia de Domínio e Desenvolvimento Baseado
Leia maisFORMULÁRIO DE REGISTRO DE PLANO DE CURSO 2013.I
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA BAIANO Campus Senhor do Bonfim I N S T I T U T O F E D E R A L D E E D U C A Ç Ã O, C I Ê N C I A E T E C N O L O G I A B A I A N O C a m p u s S E N
Leia maisArquitetura de software
Arquitetura de software Problema: vamos implementar um clone do compraentrega.com.br Mantém preços atualizados Recebe encomendas e pagamento Recomenda itens a usuários Por onde começamos? Arquitetura =
Leia maisUML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos
UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos joao.queiroz@ifrn.edu.br Roteiro A importância da UML para projetar sistemas. Principais características do diagrama de classes e de sequência.
Leia maisModelagem Estática e Dinâmica: Estudo de Caso - Sistema de Caixa Automático
Modelagem Estática e Dinâmica: Estudo de Caso - Sistema de Caixa Automático Enunciado do Problema (I) O sistema de caixa automático permite que clientes realizem saques e verifiquem seus saldos, de acordo
Leia maisModelagem de Sistemas. Análise de Requisitos. Modelagem
Modelagem de Sistemas Teoria Geral de Sistemas TADS 2. Semestre Prof. André Luís Para abordarmos de forma mais profunda os conceitos de Modelagem de Sistemas de Informação, precisamos também falar na Engenharia
Leia maisBanco de Dados I Curso: Sistemas de Informação
Banco de Dados I Curso: Sistemas de Informação Prof.: José Ronaldo Leles Júnior Email.: juniorleles80@gmail.com Alguns aspectos da arquitetura dos computadores têm influência na arquitetura do banco de
Leia maisLevantamento de classes (Análise de casos de uso) Prof. Cesar Augusto Tacla
Levantamento de classes (Análise de casos de uso) Prof. Cesar Augusto Tacla Plano Levantamento no método APOO Análise (conceitos) Projeto por padrões: MVC e Observador Estereótipos de classes Método para
Leia maisIntrodução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos
Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados
Leia maisVisões Arquiteturais. Visões Arquiteturais. Visões Arquiteturais. Visão Conceitual
Visões Arquiteturais Separar diferentes aspectos em visões separadas com o objetivo de gerenciar complexidade. Cada visão descreve diferentes conceitos da Engenharia. Visões permitem reduzir a quantidade
Leia maisMetodologias de Desenvolvimento (I)
Modelagem Estática Metodologias de Desenvolvimento (I) Método é definido como sendo um conjunto de atividades sistemáticas para realizar uma tarefa. Técnica é um modo de executar as atividades recomendadas
Leia maisPROJETO DE PROGRAMAS. Projeto de Programas PPR0001
PROJETO DE PROGRAMAS Projeto de Programas PPR0001 Desenvolvimento de Software 2 3 Desenvolvimento de Software Análise de Requisitos Distinguir e dividir o sistema em componentes: Analisar os componentes
Leia maisEA975 - Laboratório de Engenharia de Software
EA975 - Laboratório de Engenharia de Software Turmas K/L - 2017 Aula 8 Vamos inicialmente especificar com mais detalhes o termo "recurso" utilizado no estilo arquitetural REST. Em REST, recursos são uma
Leia maisEstilos Arquiteturais
Estilos Arquiteturais Estilos Arquiteturais A arquitetura de um sistema pode aderir a um ou mais estilos arquiteturais Um estilo define os tipos de elementos que podem aparecer em uma arquitetura e as
Leia maisTópicos da Aula. Diretrizes Gerais. Trabalho Prático (TP) Pontuação do TP. Tema do Trabalho. Projeto de Software Diagrama de Classes
Engenharia de Software Aula 09 Tópicos da Aula Projeto de Software Revisão de orientação a objetos Projeto orientado a objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 04
Leia maisRational Unified Process (RUP)
Rational Unified Process (RUP) A Rational é bem conhecida pelo seu investimento em orientação em objetos. A empresa foi à criadora da Unified Modeling Language (UML), assim como de várias ferramentas que
Leia maisProcesso de Desenvolvimento
Processo de Desenvolvimento RUP Rational Unified Process A Rational e o RUP 4 Rational é conhecida pelo seu investimento em orientação em objetos. 4 A empresa foi a criadora da Unified Modeling Language
Leia maisDesenvolvimento de Software Baseado em Componentes. Paulo C. Masiero
Desenvolvimento de Software Baseado em Componentes Paulo C. Masiero 1 Introdução Frustração com as promessas da Orientação a objetos em relação ao reuso de classes. Frameworks são uma solução para um domínio
Leia maisAnálise de Sistemas 4º Bimestre (material 3)
Análise de Sistemas 4º Bimestre (material 3) Permite a visualização das classes que irão compor o sistema com seus respectivos atributos e métodos, bem como demonstrar como elas se relacionam, complementam
Leia maisEngenharia de Software II
Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Engenharia de Software II Aula 07 (rogerio@fct.unesp.br) Conceitos Básicos do Rational Unified
Leia mais5 Processo de Reificação e de Desenvolvimento com ACCA
Uma Arquitetura para a Coordenação e a Composição de Artefatos de Software 53 5 Processo de Reificação e de Desenvolvimento com ACCA Resumo Este capítulo visa esclarecer e descrever atividades existentes
Leia maisEngenharia de Software. Projeto de Arquitetura
Engenharia de Software Projeto de Arquitetura O que já vimos? Introdução a Engenharia de Software Processos de Software Desenvolvimento Ágil de Software Engenharia de Requisitos Modelagem de sistemas (outra
Leia maisPROJETO DE PROGRAMAS. Projeto de Programas PPR0001
PROJETO DE PROGRAMAS Projeto de Programas PPR0001 Desenvolvimento de Software 2 3 Desenvolvimento de Software Análise de Requisitos Distinguir e dividir o sistema em componentes: Analisar os componentes
Leia maisBCD29008 Banco de dados
BCD29008 Banco de dados Modelo Entidade-Relacionamento (ER) Prof. Emerson Ribeiro de Mello Instituto Federal de Santa Catarina IFSC campus São José mello@ifsc.edu.br http://docente.ifsc.edu.br/mello/bcd
Leia maisDESENVOLVIMENTO BASEADO EM COMPONENTES
DESENVOLVIMENTO BASEADO EM COMPONENTES Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Definições de Componente de Software: Uma parte modular de um sistema, possível de ser implantada e substituível,
Leia maisModelagem Dinâmica. Toda a ação é designada em termos do fim que procura atingir. Niccolo Maquiavel. O pensamento é o ensaio da ação.
Modelagem Dinâmica Toda a ação é designada em termos do fim que procura atingir. Niccolo Maquiavel O pensamento é o ensaio da ação. Sigmund Freud Modelagem Dinâmica Identifica e modela os aspectos do sistema
Leia maisMatéria Introdutória. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri
Matéria Introdutória Banco de Dados Motivação Necessidade de armazenar grandes quantidades de dados Necessidade de acessar as informações de maneira eficiente e segura Evolução histórica: desenvolvimento
Leia maisComo Fazer Diagramas de Interação
Como Fazer Diagramas de Interação CI163 Projeto de Software Prof. Andrey Ricardo Pimentel Construindo Diagramas de Interação Os diagramas de Interação na UML mostram a troca de mensagens entre os objetos
Leia maisRUP Unified Process. Profª Jocelma Rios
RUP Unified Process Profª Jocelma Rios Nov/2012 O que pretendemos: Reforçar os aspectos que caracterizam o processo iterativo e incremental Identificar como atingir os objetivos dos projetos de software
Leia maisAnálise e Projeto Orientados a Objetos
Análise e Projeto Orientados a Objetos Modelagem conceitual do domínio Diretoria Acadêmica de Gestão e Tecnologia da Informação Introdução A modelagem do domínio está relacionada à descoberta das informações
Leia maisBanco de Dados. SGBD - Sistema de Gerenciamento de Banco de Dados Parte 2. Prof. Leonardo Vasconcelos
Banco de Dados Parte 2 Prof. Leonardo Vasconcelos - Conceitos e Arquiteturas de SBD Modelos de dados: conjunto de conceitos que podem ser usados para descrever a estrutura de um banco de dados. Permitem
Leia maisProgramação para Games II. Professor Ariel da Silva Dias Orientação a Objetos
Programação para Games II Professor Ariel da Silva Dias Orientação a Objetos Pacotes Pacotes são um modo de organizar classes e interfaces Um programa pode ser formado por centenas de classes individiduais;
Leia maisUniversidade Federal de Uberlândia Faculdade de Computação Prof. Fabiano Dorça. Introdução. Padrões de projeto
Universidade Federal de Uberlândia Faculdade de Computação Prof. Fabiano Dorça Introdução Padrões de projeto Algumas definições... Um padrão de projeto (design pattern) é uma solução geral reutilizável
Leia maisCurso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML
Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DComp 2017 Modelagem de Dados UML 2 1 Eduardo Bezerra Editora Campus/Elsevier Porcentagem de projetos que terminam dentro do
Leia maisModelagem semântica permite aproximar o modelo obtido do mundo real Exemplo de modelos:
Motivação Modelagem semântica permite aproximar o modelo obtido do mundo real Exemplo de modelos: Modelo de Entidades e Relacionamento (MER) UML (linguagem de modelagem universal) Fases de um projeto de
Leia maisModelagem de Dados e Funcional Portal XPRecife
Effektiv Solutions Modelagem de Dados e Funcional Portal XPRecife Versão Especificação dos Requisitos Data Versão: 30/ 05 / 05 Especificacao Requisitos.doc Nome Allan Rodrigo dos Santos Araújo José
Leia maisCampus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /
Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: ARQUITETURA DE SOFTWARE ASWA4 Aula N : 07
Leia maisMATA60 BANCO DE DADOS Aula 3- Modelo de Entidades e Relacionamentos. Prof. Daniela Barreiro Claro
MATA60 BANCO DE DADOS Aula 3- Modelo de Entidades e Relacionamentos Prof. Daniela Barreiro Claro Agenda Modelo de Dados MER 2 de X; X=37 Modelo de Dados O Modelo de Dados é a principal ferramenta que fornece
Leia maisMODELAGEM DE DADOS UNIDADE 2 Projeto de Banco de Dados. Luiz Leão
Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático 2.1 Projeto de banco de dados 2.2 Modelo Externo 2.3 Modelo Conceitual 2.4 Modelo Interno 2.5 Modelo Físico 2.6 Modelo de Dados
Leia maisFUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ
FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ Centro de Tecnologia - CTC Departamento de Informática - DIN Programa de Pós-Graduação em Ciência da Computação PCC ESTÁGIO DE DOCÊNCIA II Disciplina: Engenharia
Leia maisPROJETO DE BANCO DE DADOS
UNINGÁ UNIDADE DE ENSINO SUPERIOR INGÁ FACULDADE INGÁ CIÊNCIA DA COMPUTAÇÃO BANCO DE DADOS I PROJETO DE BANCO DE DADOS Profº Erinaldo Sanches Nascimento Objetivos Discutir o ciclo de vida do sistema de
Leia maisLista de Exercícios AV1
Seminários Engenharia Integrados de Usabilidade em Sistemas de Informação SEMINÁRIOS INTEGRADOS EM SISTEMAS DE INFORMAÇÃO Lista de Exercícios AV1 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão
Leia maisAnálise. Orientada a Objetos Modelo Funcional, Modelo Estrutural e Modelo Comportamental. Linguagens: Java, C++, etc.
Análise Estruturada Modelo Essencial ou Lógico constitui-se de dois sub-modelos (Modelo Ambiental e Modelo Comportamental) e um Dicionário de Dados. Linguagens: Fortran, Cobol, C, etc. Orientada a Objetos
Leia maisA modelagem de Negócio com UML
A modelagem de Negócio com UML Introdução A passagem do Modelo do Negócio para o Modelo do Sistema envolve a definição de quais Casos de Uso do Negócio deverão ser automatizados; No momento em que os requisitos
Leia maisClasses de Projeto. Prof. Anderson Cavalcanti UFRN-CT-DCA
Classes de Projeto Prof. Anderson Cavalcanti UFRN-CT-DCA Linhas Gerais sobre as Classes de Projeto Especificação de Classes de Projeto Especificação de classes de fronteira Responsáveis pela interação
Leia maisEA975 - Laboratório de Engenharia de Software
EA975 - Laboratório de Engenharia de Software Turmas K/L - 2017 Aula 1 O que vamos desenvolver? Vamos desenvolver uma aplicação distribuída, empregando a arquitetura 3-Tier segundo o estilo REST/HTTP (Respresentational
Leia maisIFSC/Florianópolis - CTI - Projeto de Sistemas - prof. Herval Daminelli
Um dos diagramas mais importantes da UML; Permite visualizar as classes que comporão o sistema, seus atributos e métodos; Demonstra como as classes do diagrama se relacionam e transmitem informações entre
Leia maisProcessos de Software
Processos de Software Um processo de software é um conjunto de atividades que leva à produção de um produto de software Um modelo de processo de software é uma representação abstrata de um processo de
Leia maisPROJETO DE ARQUITETURA (PARTE 2)
PROJETO DE ARQUITETURA (PARTE 2) Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... 5ª Lista de Exercícios Já está disponível no site a 5ª Lista de Exercícios Entrega: dia
Leia maisArquitetura de Software visão emergente
Arquitetura de Software visão emergente Objetivos Visão abstrata do software através de componentes e interfaces Independência de plataforma Independência de paradigma de programação Técnicas Estilos Arquiteturais
Leia maisDesenvolvimento de Software Baseado em Componentes. Paulo C. Masiero
Desenvolvimento de Software Baseado em Componentes Paulo C. Masiero 1 Introdução Frustração com as promessas da Orientação a objetos em relação ao reuso de classes. Frameworks são uma solução para um domínio
Leia maisIntrodução ao POO (Projeto Orientado a Objetos)
Introdução ao POO (Projeto Orientado a Objetos) BSI Bacharelado em Sistemas de Informação LOO Linguagens Orientadas a Objetos Humberto Mossri de Almeida hmossri_cursos@yahoo.com.br Marcelo Nassau Malta
Leia maisAgenda da Aula. Reuso de Software. Tipos de Reuso. Potenciais Problemas. Vantagens de Reuso. Introdução a Reuso de Software
Reuso de Software Aula 02 Agenda da Aula Introdução a Reuso de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com Introdução a Reuso de Software Abordagens de Reuso
Leia maisModelagem de Casos de Uso (Parte 2)
Modelagem de Casos de Uso (Parte 2) Método para Mod. de Casos De Uso Passos do Método: 1. Levantamento Inicial dos Casos de Uso 2. Refinamento de Casos de Usos Relacionados 3. Descrição de Casos de Usos
Leia maisBanco de Dados Modelagem e Normalização
Técnico em Informática Banco de Dados Modelagem e Normalização Profª Ana Paula Mandelli BANCO DE DADOS RELACIONAL De forma mais detalhada, um Banco de Dados Relacional é um conceito abstrato que define
Leia maisAula 13 Modelagem da Arquitetura
Aula 13 Modelagem da Arquitetura Alessandro Garcia LES/DI/PUC-Rio Setembro 2017 Especificação Objetivos dessa aula Notação de modelagem da arquitetura Realizar exercício: definição da arquitetura do programa
Leia maisAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas Prof. Dr. Ronaldo C. de Oliveira ronaldo.co@ufu.br www.facom.ufu.br/~ronaldooliveira FACOM - 2018 Diagramas de Interação de Objetos Diagramas de Interação O Diagrama de Interação
Leia maisPadrões de Projeto de Software
Padrões de Projeto de Software Lista de Exercícios AV2-01 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 Qual o objetivo dos padrões Comportamentais, segundo o catálogo GOF? Questão 1 Resposta
Leia mais2 Fluxos no Ciclo de Vida do Processo Unificado. O Processo Unificado consiste da repetição de uma série de ciclos durante a vida de um sistema.
Processo Unificado Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Ciclo de Vida - Fluxos Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia maisDocumento de Especificação de Requisitos
Documento de Especificação de Requisitos Versão: 1.0 com Modelo de Casos de Uso Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta a especificação de requisitos para a informatização
Leia maisUnidade 2 Modelo Conceitual
Unidade 2 Modelo Conceitual UFCG/CEEI/DSC Banco de Dados I Prof. Cláudio Baptista, PhD Motivação Motivação Modelagem semântica permite aproximar o modelo obtido do mundo real Exemplo de modelos: MER -
Leia mais15/04/2013. Outro Diagrama de Classes. Primeiro Diagrama de Classes. Diagrama de Classes. Atributos. Eduardo Figueiredo
DCC / ICEx / UFMG Primeiro Diagrama de Classes Diagrama de Classes Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Professor Aluno matricula Outro Diagrama de Classes Diagrama de Classes Serve de
Leia maisANHANGUERA ESTRUTURA DE DADOS AULA 02 O QUE É ESTRUTURA DE DADOS? Prof. Thomás da Costa
ANHANGUERA 2015.2 ESTRUTURA DE DADOS AULA 02 Prof. Thomás da Costa thomascosta@aedu.com Recordar é viver Lembrando Programação Estruturada: Estrutura de um programa em C++. Declaração de variáveis. Laços.
Leia mais27) Em relação aos Projetos de Sistemas de Software, assinale a sequência correta de desenvolvimento de um sistema:
Modelos de Ciclo de Vida e Metodologias de Software 33) No SCRUM, uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto é denominada: A) Backlog. B) Sprint. C) Daily scrum. D)
Leia mais