Projeto de Software. Silvia Regina Vergilio - UFPR
|
|
- Branca Flor Desconhecida Bandeira
- 6 Há anos
- Visualizações:
Transcrição
1 Projeto de Software Silvia Regina Vergilio - UFPR
2 1) Objetivos Modelos de representação do domínio (análise) Técnicas e princípios Detalhe suficiente para permitir a realização física do sistema (implementação)
3 2) Importância Fase na qual a qualidade é criada e poderá ser efetivamente avaliada. Servirá como fundamento para as fases de codificação, teste e manutenção.
4 2) Importância
5 2) Importância... tentamos resolver o problema passando rapidamente pelo processo de projeto para que sobre tempo suficiente no final para detectar e corrigir defeitos que foram introduzidos porque dedicamos pouco tempo ao projeto.
6 3) Fundamentos (Princípios) 1. Refinamento (análogo ao princípio do particionamento) decomposição 2. Arquitetura do software: um problema P pode ser solucionado por muitas estruturas candidatas
7 3) Fundamentos (Princípios)
8 3) Fundamentos (Princípios)
9 3) Fundamentos (Princípios) Módulo que controla um módulo: superior Módulo controlado por outro: subordinado Largura abertura (amplitude) da estrutura Profundidade número de níveis de controle
10 3) Fundamentos (Princípios) Fan-out: número de módulos controlados por um dado módulo Fan-in: número de módulos que controlam um dado módulo Visibilidade conjunto de componentes invocados ou utilizados até mesmo indiretamente Conectividade: conjunto de componentes diretamente invocados ou utilizados
11 3) Fundamentos (Princípios) 3. Modularidade: característica do software que permite a sua inteligibilidade, permite dividí-lo em componentes menores, chamados módulos.
12 3) Fundamentos (Princípios) 3. Modularidade: Leva a um esforço menor para resolver problemas C(x)=complexidade do problema E(x)=esforço para resolver o problema C(P1) > C(P2) E(P1) > E(P2) C(P1+P2) >C(P1)+C(P2) E(P1+P2)>E(P1) + E(P2) Como saber se eu dividi o suficiente?
13 3) Fundamentos (Princípios) 4. Abstração diferentes níveis 5. Ocultamento da Informação: princípio que diz que módulos devem ser especificados e projetados de modo que a informação (dados ou procedimento) nele contida seja inacessível a outros módulos que não tenham necessidade daquela informação
14 3) Fundamentos (Princípios) Coesão e Acoplamento Baseadas nos princípios de um bom projeto: (Yourdon, Constantine e Myers) Coesão: medida da funcionalidade de um módulo; o quanto ele realiza uma tarefa específica Acoplamento: mede o grau de interdependência entre módulos
15 (Princípios) Coesão e Acoplamento
16 3) Fundamentos (Princípios) Coesão (Deve ser alta) coincidente: o módulo realiza funções não relacionadas lógica: as funções estão relacionadas logicamente temporal: o módulo realiza mais que uma função que devem ocorrer no mesmo intervalo de tempo
17 3) Fundamentos (Princípios) Coesão procedimental: o módulo realiza mais que uma função, de tal forma que elas estão relacionadas a um procedimento geral comunicacional: o módulo realiza funções que manipulam a mesma estrutura de dados funcional: o módulo realiza uma única função bem definida
18 3) Fundamentos (Princípios) Acoplamento (Deve ser baixo) acoplamento por conteúdo: x faz referência direta ao interior de y acoplamento por common: x e y referenciam variáveis globais acoplamento por controle: x e y se comunicam por parâmetros sendo que um deles é um flag que controla o comportamento de um dos módulos
19 3) Fundamentos (Princípios) Acoplamento acoplamento por carimbo ``stamp'': x e y se comunicam por parâmetros, sendo um deles, uma estrutura de dados acoplamento por dados: x e y se comunicam por parâmetros sem acoplamento: não existe dependência
20 3. Tipos de Módulos Quanto ao tempo de incorporação macro incluído em tempo de compilação subrotina ou procedimento geração da seqüência de chamadas pelo compilador e posterior ligação. ligação dinâmica em tempo de execução.
21 3. Tipos de Módulos Quanto aos mecanismos de ativação referência chamada de subprograma interrupção programa em execução é interrompido para execução de outro módulo
22 3. Tipos de Módulos Quanto ao padrão de execução módulos convencionais um ponto de entrada e um de saída, execução sequencial e completa módulos reentrantes não possui dados locais, mais de um ponto de entrada, usado simultaneamente por mais de uma tarefa (compartilhados)
23 3. Tipos de Módulos Quanto ao relacionamento com outros módulos módulo sequencial referenciados e executados sem interrupção módulo incremental (corotinas) pode ser interrompido antes do seu término e posteriormente reiniciado
24 3. Tipos de Módulos Quanto ao relacionamento com outros módulos módulo paralelo (conrotinas) executados simultaneamente com outros módulos em ambientes concorrentes
25 4) Principais Atividades Projeto da Arquitetura do sistema do controle dos módulos Projeto dos Dados Projeto dos Procedimentos Projeto da Interface com outros Elementos do Sistema Projeto da Interface com o Usuário
26 5) Passos Projeto Geral ou Preliminar: fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos Projeto Detalhado: refinamento visando à codificação e especificação dos programas
27 6) Modelos de Projeto Geral Os modelos de projeto geral devem: especificar a decomposição do sistema em sub-sistemas (modelo da arquitetura do sistema) mostrar o relacionamento entre os subsistemas (modelo de controle do sistema) decompor os sub-sistemas em módulos (modelo da arquitetura dos módulos)
28 7) Modelo da Arquitetura do Sistema Descreve o sistema como um conjunto de sub-sistemas que fornecem um conjunto de serviços específicos. Modelos que descrevem como eles compartilham dados, como eles estão distribuídos e como é a interface entre eles.
29 7) Modelo da Arquitetura do Sistema Modelo Centralizado Supõe a existência de uma base de dados central à qual todos os subsistemas têm acesso
30 7) Modelo da Arquitetura do Sistema Modelo Centralizado
31 7) Modelo da Arquitetura do Sistema Modelo Distribuído Cada sub-sistema mantém sua própria base de dados Dados são trocados através dos subsistemas através de mensagens mais eficiente para gde quantidade de dados maior facilidade para integrar um novo subsistema permite diferentes políticas de backup, recuperação, etc
32 7) Modelo da Arquitetura do Sistema Modelo Distribuído Problemas distribuir informações pode provocar redundância e inconsistência esquemas eficientes de comunicação são necessários, recuperação, etc Modelo de arquitetura clienteservidor: O modelo + conhecido
33 7) Modelo da Arquitetura do Sistema ClienteServidor Mostra como se dá a distribuição dos serviços através dos sub-sistemas Composto de: um conjunto de servidores: oferecem serviços específicos. Ex: servidores de impressão, compilação, etc. um conjunto de clientes: que utilizam os serviços (podem ser várias instâncias de um mesmo cliente) uma rede de comunicação A arquitetura três-camadas: + utilizada
34 7) Modelo da Arquitetura do Sistema ClienteServidor
35 7) Modelo da Arquitetura do Sistema ClienteServidor
36 8) Modelo de Controle do Sistema Especificam as relações de controle entre os sub-sistemas Controle centralizado: um sub-sistema é responsável por controlar, iniciar e parar os outros sistemas Controle baseado em eventos: Cada sub-sistema pode responder a eventos externos ou originados no próprio sistema
37 8) Modelo de Controle do Sistema Controle Centralizado Exemplo1 : Exemplo2 :
38 8) Modelo de Controle do Sistema - Baseado em Eventos
39 8) Modelo de Controle do Sistema - Baseado em Eventos
40 9) Diagrama de Pacotes da UML Um pacote é um conjunto de elementos agrupados. Esses elementos podem ser classes, diagramas, ou até mesmo outros pacotes.
41 9) Diagrama de Pacotes da UML
42 9) Diagrama de Pacotes da UML Modelo Três Camadas Apresentação: janelas, relatórios Aplicação: registrar vendas, autorizar pagamentos Armazenamento: BD Pode-se separar a camanda da aplicação em diferentes componentes a serem reutilizados Diferentes equipes para o desenvolvimento Camadas distribuídas em um sistema cliente servidor aumentam desempenho
43 9) Diagrama de Pacotes da UML Modelo Três Camadas
44 9) Diagrama de Pacotes da UML Camada do Domínio
45 9) Diagrama de Pacotes da UML Exemplo
46 9) Diagrama de Pacotes da UML Padrões para construir Padrão Domínio-Apresentação Separados (Modelo-Visão Separados) Problema: Separar apresentação da camada do domínio para aumentar reuso e diminuir impacto de mudanças. Solução: As classes da apresentação não mantêm dados, apenas realizam E/S, acoplamento mínimo de objetos do domínio com janelas da apresentação.
47 9) Diagrama de Pacotes da UML Padrões para construir
48 10) Modelo da Arquitetura dos Módulos Especifica a decomposição de cada subsistema em módulos Orientados a funções: os sub-sistemas são decompostos em módulos funcionais que recebem dados e transformam estes dados em saída (ex:diagrama hierárquico de funções) Orientado a objetos: os sub-sistemas são decompostos em um conjunto de objetos que se comunicam para resolver o problema (ex:diagramas de interação -UML)
49 11) Diagrama Hierárquico de Funções - DHF É obtido a partir do DFD e representa como os módulos (processos/bolhas) são organizados a fim de compor a solução Também representa controle hierarquia
50 11) Diagrama Hierárquico de Funções - DHF
51 11) Diagrama Hierárquico de Funções - DHF
52 11) Diagrama Hierárquico de Funções(DHF) Como construir São três passos 1. Identificar a categoria do fluxo de informação transformação ou transação 2. Revisar DFD s e mapeá-los para o DHF 3. Revisar o diagrama através de regras de projeto e acrescentar se necessário módulos de tratamento de erros e excessão
53 11) Diagrama Hierárquico de Funções(DHF) Como construir 1. Identificando o Fluxo Fluxo de Transformação
54 11) Diagrama Hierárquico de Funções(DHF) Como construir 1.Identificando o Fluxo Fluxo de Transação
55 11) Diagrama Hierárquico de Funções(DHF) Como construir 2. Mapeamento do Fluxo de Transformação
56 11) Diagrama Hierárquico de Funções(DHF) Como construir 2. Mapeamento do Fluxo de Transformação
57 11) Diagrama Hierárquico de Funções(DHF) Como construir 2. Mapeamento do Fluxo de Transação
58 11) Diagrama Hierárquico de Funções(DHF) Como construir 2. Mapeamento do Fluxo de Transação
59 11) Diagrama Hierárquico de Funções(DHF) Como construir 3. Revisar a estrutura Regras de Projeto 1. Reduzir acoplamento e aumentar explosão de módulos coesão implosão de módulos
60 11) Diagrama Hierárquico de Funções(DHF) Como construir 2. Minimizar estruturas com fan-in e fan-out, aumentando fan-in à medida que a profundidade aumenta estrutura oval 3. Manter o escopo do efeito de um módulo dentro do escopo de controle do módulo 4. Reduzir complexidade das interfaces entre os módulos 5. Evitar módulos muito restritivos portabilidade 6. Utilizar ED as menos complexas possíveis
61 12) Diagramas de Interação Ilustram como objetos interagem via mensagens e como realizam tarefas com o objetivo de cumprir as pós-condições dos contratos. Diagramas de Colaboração grafo ou rede Diagramas de Sequências traços de eventos
62 12) Diagramas de Interação
63 12) Diagramas de Interação
64 12.1) Diagrama de Colaboração - Notação
65 12.1) Diagrama de Colaboração - Notação
66 12.1) Diagrama de Colaboração - Notação
67 12.1) Diagrama de Colaboração Notação
68 12.1) Diagrama de Colaboração Notação
69 12.1) Diagrama de Colaboração Notação
70 12.1) Diagrama de Colaboração Notação
71 12.1) Diagrama de Colaboração Notação
72 12.1) Diagrama de Colaboração Notação
73 12.1) Diagrama de Colaboração Notação
74 12.1) Diagrama de Colaboração Notação
75 12.1) Diagrama de Colaboração Notação
76 12.1) Diagrama de Colaboração Notação
77 12.1) Diagrama de Colaboração Notação
78 12.2) Diagrama de Colaboração e Outros Modelos
79 12.3) Diagrama de Colaboração Como Construir Atribuir responsabilidades: parte difícil e importante Auxílio: uso de ``patterns'' que são diretrizes e princípios a serem aplicados Criar um diagrama para cada operação do sistema; para cada msg de operação do sistema, fazer um diagrama com ela sendo a msg inicial
80 12.3) Diagrama de Colaboração Como Construir Se o diagrama ficar complexo, divida-o em diagramas menores Usando responsabilidades e pós condições dos contratos e, a descrição de caso de uso como ponto inicial, projete objetos interagindo para completar as tarefas. Métodos: cumprem as responsabilidades.
81 12.3) Diagrama de Colaboração Como Construir Responsabilidades: Contrato ou obrigação de uma classe: saber: saber sobre os seus dados, sobre objetos relacionados, sobre coisas que ele pode calcular ou derivar. fazer: iniciar ações entre outros objetos, controlar e coordenar atividades em outros objetos Aplique padrões para fazer um bom projeto e para estabelecer os métodos e operações de cada objeto.
82 12.4) Diagrama de Colaboração Padrões Grasp Padrões: contêm descrições de um problema e uma solução que pode ser utilizada em diferentes contextos. Codificam idéias e heurísticas existentes para atribuir responsabilidades a objetos. Padrões GRASP básicos: especialista, criador, alta coesão, baixo acoplamento, controle.
83 12.4) Diagrama de Colaboração Padrões Grasp 1. Padrão Especialista (Expert) Solução: Atribua uma responsabilidade a uma classe que possui a informação necessária para cumprí-la. Problema: Quem deveria ser responsável por calcular o total-geral de uma venda? a classe Venda possui a informação para isso
84 12.4) Diagrama de Colaboração Padrões Grasp Classe Responsabilidade sabe total geral da Venda venda sabe sub-total de Item de Venda cada item Especificação do sabe preço do Produto produto
85 12.4) Diagrama de Colaboração Padrões Grasp
86 12.4) Diagrama de Colaboração Padrões Grasp
87 12.4) Diagrama de Colaboração Padrões Grasp 2. Padrão Criador (Creator) Solução: Atribua à classe B a responsabilidade de criar uma instância da classe A se: B agrega objetos de A B contém A B armazena instâncias de A B usa objetos de A B possui informação necessária a criação de A (B é um especialista para criar A)
88 12.4) Diagrama de Colaboração Padrões Grasp 2. Padrão Criador (Creator) Problema: Quem deveria ser responsável por criar a instância da classe Item de Venda? classe Venda agrega muitos objetos da classe Itens de Venda
89 12.4) Diagrama de Colaboração Padrões Grasp
90 12.4) Diagrama de Colaboração Padrões Grasp 3. Padrão Baixo Acoplamento e Padrão Alta Coesão (Low Coupling e High Cohesion) Solução: Atribua responsabilidades para garantir baixo acoplamento (mede a independência da classe em relação a outras) e alta coesão (medida de relacionamento entre as responsabilidades de uma classe)
91 12.4) Diagrama de Colaboração Padrões Grasp Problema: Para evitar que a classe seja: constantemente afetada por mudanças em outras classes difícil de compreeder quando isolada difícil de ser reusada sem as outras classes difícil de manter que classe poderia criar uma instância da classe Pagato?
92 12.4) Diagrama de Colaboração Padrões Grasp
93 12.4) Diagrama de Colaboração Padrões Grasp 4. Padrão Controle (Controller) Solução: Atribua responsabilidades para lidar com mensagens de eventos do sistema a uma classe que: represente o sistema como um todo represente a organização represente algo ativo no mundo real envolvido na tarefa (por exemplo o papel de uma pessoa) represente um controlador artificial dos eventos de sistema de um caso de uso
94 12.4) Diagrama de Colaboração Padrões Grasp Problema: Quem deveria ser responsável por lidar com um evento do sistema? um controlador é um objeto de interface responsável por gerenciar um evento do sistema, definindo métodos para operações do sistema Quem deveria ser o controlador para eventos do sistema tais como entraritem e Vendafim?
95 12.4) Diagrama de Colaboração Padrões Grasp
96 12.4) Diagrama de Colaboração Padrões Grasp 4. Padrão Controle Use o mesmo controlador para todos os eventos do sistema no mesmo caso de uso Classes do tipo janela, applet, aplicações, documento não deveriam realizar tarefas associadas a eventos do sistema. Elas apenas recebem e delegam os eventos ao controlador Um evento do sistema é gerado por um ator
97 12.4) Diagrama de Colaboração Padrões Grasp Um controlador não deve ter muitos atributos e nem manter informação sobre o domínio do problema Um controlador não deve realizar muitas tarefas, apenas delegá-las Um bom projeto deve dar vida aos objetos, atribuindo-lhes responsabilidades, até mesmo se eles forem seres inanimados A camada de apresentação (interface com o usuário) não deve tratar eventos do sistema
98 12.4) Diagrama de Colaboração Padrões Grasp 5. Padrão Comando Problema: Aplicações que recebem msg de um sistema externo (não existe interface com o usuário). Ex: sistemas de telecomunicações Solução: definir uma classe para cada comando, com o método executar. O controlador criará uma instância da classe correspondente a msg do evento do sistema e enviará a mensagem executar à classe comando.
99 12.4) Diagrama de Colaboração Padrões Grasp
100 12.4) Diagrama de Colaboração Padrões Grasp
101 12.4) Diagrama de Colaboração Como Construir utilize as responsabilidades e póscondições dos contratos e use casos de usos como ponto de partida escolha a classe que controlará o sistema, aplicar padrão controle para cada operação existe um contrato, uma operação vai ser uma mensagem.
102 12.4) Diagrama de Colaboração Como Construir separação do modelo de visão: não é responsabilidade dos objetos do domínío se comunicarem com o usuário (ignorar responsabilidades de apresentação dos dados no display, mas toda informação do domínio de objetos tem que ser mostrada) para um objeto enviar uma msg a outro é necessário visibilidade: habilidade de um objeto ver ou fazer referência a outro objeto
103 12.4) Diagrama de Colaboração Como Construir
104 12.5) Diagrama de Colaboração - Visibilidade Habilidade de um objeto A ver ou fazer referência a um outro objeto B. Para A enviar uma msg para B, B deve ser visível a A. por atributo: B é um atributo de A por parâmetro: B é um parâmetro de um método de A localmente declarada: B é um objeto local de um método de A; uma instância local é criada, ou ele será um valor de retorno global: B é visível globalmente; usa-se uma variável global para armazenar uma instância pouco recomendada
105 12.5) Diagrama de Colaboração - Visibilidade
106 12.5) Diagrama de Colaboração - Visibilidade
107 12.6) Diagrama de Colaboração - Exemplos
108 12.6) Diagrama de Colaboração - Exemplos
109 12.6) Diagrama de Colaboração - Exemplos
110 12.6) Diagrama de Colaboração - Exemplos
111 12.6) Diagrama de Colaboração - Exemplos
112 12.6) Diagrama de Colaboração - Exemplos
113 12.7) Diagrama de Colaboração - Inicializando Como se realizam as operações iniciais da aplicação? Cria-se um caso de uso startup. Seu diagrama de colaboração deve ser criado por último, representando o que acontece quando o objeto inicial do problema é criado. Quem deveria ser o objeto inicial do sistema? classe representando toda a informação lógica do sistema classe representando a organização usar Padrões Alta Coesão e Baixo Acoplamento
114 12.7) Diagrama de Colaboração - Inicializando
115 12.7) Diagrama de Colaboração - Inicializando
116 12.7) Diagrama de Colaboração - Inicializando Conectando a camada de apresentação com a do domínio Uma operação de startup pode ser: uma mensagem ``create'' para o objeto inicial; se o objeto inicial é o controlador, uma mensagem ``run'' para um objeto inicial é enviada.
117 12.7) Diagrama de Colaboração - Inicializando Se uma interface do usuário estiver envolvida ela é responsável por iniciar a criação do objeto inicial e outros associados. Objetos da camada de apresentação não devem ter responsabilidades lógicas. Das nossas escolhas resultarão extensibilidade, claridade e manutenibilidade
118 12.7) Diagrama de Colaboração - Inicializando
119 13) Diagrama de Classes Modelo Conceitual Estendido acréscimo de métodos, tipos dos atributos, visibilidade e navegabilidade, inclui a visão de projeto além da visão de domínio
120 13) Diagrama de Classes Como construir identificar todas as classes participantes da solução através dos diagramas de colaboração desenhar o diagrama copiar os atributos adicionar os métodos dos diagramas de interação adicionar tipos de atributos, parâmetro e retornos de métodos.
121 13) Diagrama de Classes Como construir adicionar as associações necessárias a visibilidade adicionar navegabilidade que indica a direção de visibilidade por atributo adicionar setas pontilhadas indicando visibilidade que não é por atributo Métodos ``create'' e de acessos aos atributos podem ser omitidos. Os tipos podem ou não ser mostrados; classes podem ser detalhadas ao máximo
122 13) Diagrama de Classes Exemplos
123 13) Diagrama de Classes Exemplos
124 13) Diagrama de Classes Exemplos
125 14) Modelos de Projeto Detalhado O projeto detalhado concentra-se no aprimoramento ou refinamento Gera representações/especificações das estruturas de dados e representações algorítimicas Utiliza ferramentas Gráficas : fluxogramas, cartas N S, diagramas de ação Tabulares : tabelas de decisão. Linguagens : pseudo código PDL ( Program Design Language )
126 14) Ferramentas de Projeto Detalhado Fluxograma processamento controle cond cond Proc 1 Parte else condição Parte then V F Proc 2 sequência processamento if then else (condição) controle do while (repetição) condição Proc
127 14) Ferramentas de Projeto Detalhado Fluxograma C1 Proc1 Proc C2 Proc2... Cn Proc n COND F V REPEAT UNTIL (Repetição) CASE (Seleção)
128 14) Ferramentas de Projeto Detalhado Fluxograma Ex. 1 Proc. Próximo Proc. F F ELSE V V THEN ELSE V THEN Proc saídas
129 14) Ferramentas de Projeto Detalhado Fluxograma Fácil de entender e projetar; Problema : existência de jump, permite a violação dos princípios de programação estruturada.
130 14) Ferramentas de Projeto Detalhado Cartas NS sequência Proc1 Proc2... if then else F Cond Parte ELSE V Parte THEN do while COND repeat until PROC PROC COND
131 14) Ferramentas de Projeto Detalhado Cartas NS case (seleção) repetição infinita DO FOREVER Valor Cond Valor... Valor proc1 proc2 Proc n... PROC delimitação BEGIN PROC END
132 14) Ferramentas de Projeto Detalhado Cartas NS a b x1 F Case xi, i = 2,3,4 x3 x2 V f x6 x4 V x5 g c d i e h x7 x8 j
133 14) Ferramentas de Projeto Detalhado Cartas NS Vantagens Cartaz N S : escopo da iteração e do if then else é bem definido e visível. transferências arbitrárias são impossíveis. escopo das variáveis é obvio. estruturas completas podem caber dentro de um programa. codificação é direta. pode servir como um guia para testes (ramos testados). serve como documentação. Desvantagens : problemas de espaço e estruturas rígidas.
134 14) Ferramentas de Projeto Detalhado Tabelas de Decisão Condições IF AND AND AND THEN AND Ações Canhotos\Entradas C1 C2 C3 C4 A1 A2 RD1 RD2 RD3 RD4 Regra de decisão
135 14) Ferramentas de Projeto Detalhado Tabelas de Decisão Ex.: Tabela de linhas de Entrada Limitada Condições : S a condição deve ser satisfeita N a condição não deve ser satisfeita a condição é irrelevante Ações : X a ação correspondente deve ser executada a ação correspondente deve ser ignorada
136 14) Ferramentas de Projeto Detalhado Tabelas de Decisão Limite de Crédito Satisfatório Crédito na Praça Favorável Liberação Especial Aprovada Aprovar Pedido Rejeitar Pedido Rd1 5 x - RD2 N S x - RD3 N N S x - RD4 N N N x
137 14) Ferramentas de Projeto Detalhado Tabelas de Decisão As tabelas podem ser facilmente automatizadas Facilidade para reduzir redundâncias; Verificar dependências e contradições. Não mostra laços. Não existe correspondência direta entre tabela e algoritmo.
138 14) Ferramentas de Projeto Detalhado Pseudocódigo Linguagem natural + sintaxe de linguagens de programação. Palavras chaves para estruturação, declaração de dados e modularização. Sintaxe livre para descrever processamento. Pode se declarar dados e interfaces entre módulos. Tradução para o programa é direta. Exitem muitas ferramentas disponíveis. Pode ser ambíguo.
139 14) Ferramentas de Projeto Detalhado Comparação Para comparação, utilizar: possibilidades de representar modularidade; simplicidade; facilidade de edição; facilidade de automação; manutenção; representação de dados; conversão para código; testabilidade e lógica.
Padrões de Projeto de Software
Padrões de Projeto de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático Padrões Básicos Information Expert Creator High Cohesion Low Coupling Controller Padrões Avançados
Leia maisIntrodução. descrever os tipos de interfaces e linguagens oferecidas por um SGBD. mostrar o ambiente de programas dos SGBD s
Introdução Contribuição do Capítulo 2: discutir modelos de dados definir conceitos de esquemas e instâncias descrever os tipos de interfaces e linguagens oferecidas por um SGBD mostrar o ambiente de programas
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 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 maisEngenharia de Software. Projeto de Software. Projeto: definição. Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff
Engenharia de Software Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff Projeto de Software Fundamentos de projeto de software Projeto estruturado Índice do documento de projeto
Leia maisSSC Engenharia de Software. Prof. Paulo C. Masiero
SSC - 5764 Engenharia de Software Prof. Paulo C. Masiero Processo de Software: Fases ou Subprocessos DEFINIÇÃO CONSTRUÇÃO MANUTENÇÃO Análise de Sistema Análise de Requisitos Projeto Projeto Processo pelo
Leia maisEngenharia de Software
Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 UML Linguagem Unificada de Modelagem Projeto de Software Introdução O que é projeto em software? O termo projeto é um tanto
Leia maisGRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES. SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa
GRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2016 1 RESPONSABILIDADE Responsabilidade um contrato ou
Leia maisCONCEITOS DE PROJETOS - 2. Profa. Reane Franco Goulart
1 CONCEITOS DE PROJETOS - 2 Profa. Reane Franco Goulart MODULARIDADE A arquitetura do software incorpora a modularidade, isto é, o software é dividido em componentes nomeados separadamente e endereçáveis,
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 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 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 maisGRASP. Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)
GRASP Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Introdução a padrões O que são? Por que utilizá-los? Padrões GRASP O que são? Quais serão apresentados na disciplina?
Leia maisIntrodução ao Projeto. Projeto de Software. 1) Objetivos. 2) Importância. Análise e Projeto - Diferenças. Importância. Silvia Regina Vergilio - UFPR
Introdução ao Projeto Projeto de Software Silvia Regina Vergilio - UFPR 1. Objetivos 2. Importância 3. Fundamentos 4. O processo de projeto 5. Métodos de projeto 6. Analisando a estrutura do software 1)
Leia maisARCHITECTURAL DESIGN. Ian Sommerville, 8º edição Capítulo 11 Aula de Luiz Eduardo Guarino de Vasconcelos
ARCHITECTURAL DESIGN Ian Sommerville, 8º edição Capítulo 11 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Tópicos abordados Arquitetura de Software Projeto de arquitetura Vantagens de arquitetura
Leia maisMODELAGEM DE SISTEMAS Unidade 4 Modelo de Classes de Projeto. Luiz Leão
Unidade 4 Modelo de Classes de Projeto Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático Definição da Visibilidade entre Objetos Adição de Operações às Classes de Projeto Adição
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 maisIntrodução à Análise e Projeto de Sistemas
Introdução à I. O Que vamos fazer na Disciplina? Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO Tem que saber Análise e Projeto OO (APOO) Isto é, Análise
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 maisDiagrama de Colaboração Exemplos - Padrões GRASP Diagrama de Classes
Diagrama de Colaboração Exemplos - Padrões GRASP Diagrama de Colaboração Exemplos - Padrões GRASP Diagrama de Colaboração Exemplos - Padrões GRASP Diagrama de Classes Modelo de classes de especificação
Leia maisEngenharia de Software
Engenharia de Software Design Principles Representando SW em UML OO em C Pattens úteis para embedded Rodrigo M A Almeida Design Principles Design Principles são guias para decompor as funcionalidades e
Leia maisProjeto Orientado a Objetos
Projeto Orientado a Objetos Ivan Mathias Filho Toacy Cavalcante de Oliveira Design Orientado a Objetos Após a identificação dos requisitos e a criação do modelo de domínio, devemos adicionar os métodos
Leia maisAnálise e projeto de sistemas
Análise e projeto de sistemas Conteúdo: UML O processo de desenvolvimento de software Prof. Patrícia Lucas A linguagem de modelagem unificada (UML) A UML teve origem em uma tentativa de se unificar os
Leia maisIntrodução a UML (Unified Modeling Language)
Introdução a UML (Unified Modeling Language) O que é a UML? Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário
Leia maisNotas de Aula 03: Introdução a Orientação a Objetos e a UML
Notas de Aula 03: Introdução a Orientação a Objetos e a UML Objetivos da aula: Introduzir os conceitos da Orientação à Objetos (O.O) Introduzir os conceitos da UML Relacionar os processos às ferramentas
Leia maisAnálise e Projeto Orientados a Objetos: Visibilidade Diagrama de Classe de Projeto
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientados a Objetos: Visibilidade Diagrama de Classe
Leia maisPrincípios da Engenharia de Software aula 03
Princípios da Engenharia de Software aula 03 Prof.: José Honorato Ferreira Nunes Material cedido por: Prof.: Franklin M. Correia Na aula anterior... Modelos de processos de software: Evolucionário Tipos
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 maisARQUITETURA E DESENHO
ARQUITETURA E DESENHO DE SOFTWARE CMP 1063 Prof. Me. Fábio Assunção Parte 2 DESENHO DE SOFTWARE Espaço do problema Espaço da solução. Interpretação não literal. Orientação à escrita. Orientação à diagramação.
Leia maisMANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO
MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO Sumário PREFÁCIO...3 MODELO DA DOCUMENTAÇÃO...3 1. INTRODUÇÃO AO DOCUMENTO...3 1.1. Tema...3 2. DESCRIÇÃO
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 maisUML e seus diagramas
UML e seus diagramas A UML Unified Modeling Language (Linguagem de Modelagem Unificada), como o próprio nome já diz, é uma linguagem para modelagem de objetos do mundo real, usada para especificar, construir,
Leia maisUML. Rodrigo Leite Durães.
UML Rodrigo Leite Durães. rodrigo_l_d@yahoo.com.br O que é Análise de Software? UML: É o estágio de um sistema que captura os requisitos e o domínio do problema, focalizando no que deve ser feito, não
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 maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
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 maisPrincípios e Conceitos de Desenho de Software. Projeto de Sistemas de Software Prof. Rodrigo Ribeiro
Princípios e Conceitos de Desenho de Software Projeto de Sistemas de Software Prof. Rodrigo Ribeiro Revisando... Processo Unificado PRAXIS Processo unificado: Dividido em fases e fluxos Fases Concepção,
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 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 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 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 maisProjeto de Arquitetura
Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto
Leia maisAnálise e Projeto de Software
Análise e Projeto de Software Proj. Desenvolvimento de Software Prof. Cleverton Hentz cleverton.hentz@ifrn.edu.br 8 de junho de 2017 Material Apresentado Sumário de Aula 1 Introdução 2 Estruturação do
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 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 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 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 mais6.1. Teste Baseado em Gramática e Outras Abordagens de Teste
6 Discussão Além das técnicas de teste usando modelos gramaticais, existem outras abordagens de teste funcional de sistemas que estão sendo estudadas pela comunidade científica. Algumas delas se dedicam
Leia maisSEMINÁRIOS INTEGRADOS EM SISTEMAS DE INFORMAÇÃO. Luiz Leão
SEMINÁRIOS INTEGRADOS EM SISTEMAS DE INFORMAÇÃO Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático 4.1. Aplicações utilizando Programação Estruturada e Programação Orientada a Objeto.
Leia maisProcessos de software
Processos de software 1 Processos de software Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software. 2 Objetivos Introduzir modelos de processos 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 do problema. Desenvolvimento de programas. Desenvolvimento do algoritmo. Análise do problema
Desenvolvimento de programas 1 Análise do problema 2 Análise do problema Desenvolvimento do algoritmo Codificação do programa Compilação e execução Teste e depuração Conhecer exatamente o que o problema
Leia maisIntrodução a Padrões, GRASP. Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé)
Introdução a Padrões, GRASP Nazareno Andrade (baseado no material de Hyggo Almeida e Jacques Sauvé) O que vimos na última aula? Processo de Desenvolvimento de Software Visão geral de processo Processos
Leia maisProgramação I Apresentação
Programação I Apresentação Prof. Carlos Alberto carlos.batista@facape.br carlos36_batista@yahoo.com.br Referências JUNIOR, D. P.; NAKAMITI, G. S.; ENGELBRECHT, A. de M. E.; BIANCHI, F. Algoritmos e Programação
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 maisProf. Me. Sérgio Carlos Portari Júnior
Prof. Me. Sérgio Carlos Portari Júnior Ambientes que visam desenvolver aplicações que precisam de um processamento paralelo e distribuído deverão saber lidar com algumas dificuldades. Isto decorre da heterogeneidade
Leia maisProcessos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1
Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando
Leia maisDesenvolvimento de programas. Análise do problema. Análise do problema. Análise do problema. Desenvolvimento do algoritmo. Codificação do programa
Desenvolvimento de programas 1 Análise do problema Desenvolvimento do algoritmo Codificação do programa Compilação e execução Teste e depuração Análise do problema 2 Conhecer exatamente o que o problema
Leia maisDesenvolvimento de programas
1 Desenvolvimento de programas Análise do problema Desenvolvimento do algoritmo Codificação do programa Compilação e execução Teste e depuração 2 Análise do problema Conhecer exatamente o que o problema
Leia maisProjeto de software Estrutura do software e arquitetura SWEBOK
Projeto de software Estrutura do software e arquitetura SWEBOK SWEBOK Design Patterns Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas da engenharia Design
Leia maisBibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.
Bibliografia Quais são os problemas? 4 A sofisticação do software ultrapassou nossa capacidade de construção. 4 Nossa capacidade de construir programas não acompanha a demanda por novos programas. 4 Nossa
Leia maisModelagem Orientada a Objeto
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Modelagem Orientada a Objeto Engenharia de Software 2o. Semestre de
Leia maisUniversidade Federal da Paraíba CCEN Departamento de Informática Disciplina: Banco de Dados. Aula 1 Introdução a Banco de Dados
Universidade Federal da Paraíba CCEN Departamento de Informática Disciplina: Banco de Dados Aula 1 Introdução a Banco de Dados 1. Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído
Leia maisAULA 02. OBJETIVO: Características da Linguagem Orientada a Objetos.
AULA 02 OBJETIVO: Características da Linguagem Orientada a Objetos. HABILIDADES TRABALHADAS: Comparação das características das linguagens orientadas a objetos frente às linguagens estruturadas. Conhecimentos
Leia maisREUSO E REUSABILIDADE
REUSO E REUSABILIDADE Manutenção de Software Profa. Cynthia Pinheiro Antes de mais nada... 2ª Lista de Exercícios Já está disponível no site a 2ª Lista de Exercícios Entrega: dia 03/10, no horário da aula.
Leia maisAnálise Estruturada. Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.
Análise Estruturada Análise estruturada Proposta a partir de 1975 por vários autores (Constantine, Tom DeMarco, Yourdon, Gane & Sarson) Caiu em desuso com os modelos orientados a objetos Entretanto...
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 maisAnalista de Sistemas S. J. Rio Preto
RATIONAL ROSE TUTORIAL Conteúdo: 1. Bem-vindo ao Rational Rose tutorial Rational Rose é um conjunto de ferramentas de modelagem visual usadas para desenvolvimento de soluções de software eficientes, robustas,
Leia maisNormalização de dados
1 Normalização de dados Vantagens da normalização A normalização permite: Agrupar os atributos de uma entidade de forma a reduzir o número de dependências funcionais existentes entre os dados numa base
Leia maisDIAGRAMAS DE CLASSE UML
DIAGRAMAS DE CLASSE UML Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Calendário de Reposições Aula 1: 27/10/2017, 8h-10h, Sala 8 Aula 2: A verificar Aula 3: A verificar
Leia maisAula 4 POO 1 Análise OO. Profa. Elaine Faria UFU
Aula 4 POO 1 Análise OO Profa. Elaine Faria UFU - 2019 Sobre o Material Agradecimentos Aos professores José Gustavo e Fabiano, por gentilmente terem cedido seus materiais. Os slides consistem de adaptações
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 4 Design Baseado em Responsabilidades 1 Programa Capítulo 4 Design Baseado em Responsabilidades
Leia maisModelagem Usando Orientação à Objetos (Programação Orientada a Objetos) Prof. Responsáveis Wagner Santos C. de Jesus
Curso Disciplina Linguagem de Programação II Curso Engenharia da Computação Modelagem Usando Orientação à Objetos (Programação Orientada a Objetos) Site : http://www1.univap.br/~wagner/ec.html Prof. Responsáveis
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 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 maisRUP RATIONAL UNIFIED PROCESS
O que é RUP? É um metodologia para gerenciar projetos de desenvolvimento de software que usa a UML como ferramenta para especificação de sistemas. Ele é um modelo de processo híbrido Mistura elementos
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 maisUML (Unified Modelling Language)
UML (Unified Modelling Language) Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Booch, G. et al. The Unified Modeling Language User Guide
Leia maisCapítulo 6 Design da Arquitectura
Capítulo 6 Design da Arquitectura Capítulo 6 Design da Arquitetura 1 Assuntos abordados Decisões de design de arquitectura Visões de arquitetura Padrões de arquitetura Arquiteturas de aplicativos Capítulo
Leia maisANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3)
ANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3) Profª Andrea Padovan Jubileu Desenvolvimento Iterativo de Software (LARMAN, 2007) Desenvolvendo Software com UML 2.0 (MEDEIROS, 2004) Modelo de Projeto O
Leia maisSISTEMAS DE BANCOS DE DADOS: CONCEITOS E ARQUITETURA
Fundação Centro de Análise, Pesquisa e Inovação Tecnológica Instituto de Ensino Superior - FUCAPI SISTEMAS DE BANCOS DE DADOS: CONCEITOS E ARQUITETURA Disciplina: Banco de Dados Prof: Márcio Palheta, Esp.
Leia maisIntrodução a Teste de Software
Universidade Católica de Pelotas Tecnólogo em Análise e Desenvolvimento de Sistemas Disciplina de Qualidade de Software Introdução a Teste de Software Prof. Luthiano Venecian 1 Conceitos Teste de software
Leia maisTópicos da Aula. A Linguagem UML. A Linguagem UML. De onde surgiu? Fundadores da UML. Introdução à UML e Diagrama de Casos de Uso.
Engenharia de Software Aula 07 Tópicos da Aula Introdução à UML e Introdução a UML Visão geral de alguns diagramas Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 28 Março 2012 A
Leia maisKorth Silberschatz Sundarshan. Sistema de Banco de Dados, 5/E
Sistema de Banco de Dados, 5/E Capítulo 1: Introdução Finalidade dos sistemas de banco de dados Visão dos dados Linguagens de banco de dados Bancos de dados relacionais Projeto de banco de dados Bancos
Leia maisGerência de Projetos e Qualidade de Software. Prof. Walter Gima
Gerência de Projetos e Qualidade de Software Prof. Walter Gima 1 OBJETIVO Compreender uma série de técnicas de testes, que são utilizadas para descobrir defeitos em programas Conhecer as diretrizes que
Leia maisBanco de Dados. Aula 2 - Prof. Bruno Moreno 19/08/2011
Banco de Dados Aula 2 - Prof. Bruno Moreno 19/08/2011 Aula passada.. Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza
Leia maisAlgoritmos e Estruturas de Dados I (DCC/003) Estruturas Condicionais e de Repetição
Algoritmos e Estruturas de Dados I (DCC/003) Estruturas Condicionais e de Repetição 1 Comando while Deseja-se calcular o valor de: 1 + 2 + 3 +... + N. Observação: não sabemos, a priori, quantos termos
Leia maisPanorama da notação UML
Panorama da notação UML A notação UML (Unified Modeling Language linguagem de modelagem unificada) evoluiu desde que foi adotada a primeira vez como um padrão em 1997. Uma revisão maior para o padrão foi
Leia maisINSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE
1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE Nickerson Fonseca Ferreira nickerson.ferreira@ifrn.edu.br O que é?? 2 A UML
Leia maisResumo parcial da Tese de Doutorado. Um modelo de Sistema de Gestão do Conhecimento para grupos de pesquisa e desenvolvimento.
Universidade Federal de Santa Catarina Centro Tecnológico Disciplina: PROJETOS I Aluno: Cleosvaldo G. Vieira Jr cgvjr@inf.ufsc.br Resumo parcial da Tese de Doutorado Um modelo de Sistema de Gestão do Conhecimento
Leia mais3 Arquitetura para a Coordenação e a Composição de Artefatos de Software
Uma Arquitetura para a Coordenação e a de Artefatos de 23 3 Arquitetura para a Coordenação e a de Artefatos de Resumo Este capítulo apresenta a arquitetura ACCA, que é a parte central deste trabalho. A
Leia maisS15 - Engenharia de Requisitos continuação cap.6
S15 - Engenharia de Requisitos continuação cap.6 ENGENHARIA DE SOFTWARE PRESSMAN, 2011 Gilberto Wolff UTFPR Roteiro Análise de requisitos Modelagem baseada em cenários Modelos UML que complementam o Caso
Leia maisUML Diagrama de Atividades Diagrama de Caso de Uso. ENG1518/3VB Sistemas de Informação Gerenciais Prof. Marcos Villas
Diagrama de Atividades Diagrama de Caso de Uso ENG1518/3VB Sistemas de Informação Gerenciais Prof. Marcos Villas villas@puc-rio.br 1 - Conceitos 2 UML é uma linguagem para: Especificar Visualizar Construir...
Leia maisA modelagem é tida como a parte central de todas as atividades para a construção de um bom sistema, com ela podemos:
Módulo 6 Análise Orientada a Objeto É interessante observar como a análise orientada a objeto utiliza conceitos que aprendemos há muito tempo: objetos, atributos, classes, membros, todos e partes. Só não
Leia maisPOO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos
UEG - Universidade Estadual de Goiás (Câmpus Posse) Disciplina: Análise e Projeto de Sistemas II Turma: 4 Semestre Ano: 2016 Professor: José Ronaldo Leles Júnior O que é? É uma forma de abordar um problema.
Leia mais27/02/2016 UML. Prof. Esp. Fabiano Taguchi DIAGRAMAS DE SEQUÊNCIA
UML Prof. Esp. Fabiano Taguchi http://fabianotaguchi.wordpress.com fabianotaguchi@hotmail.com DIAGRAMAS DE SEQUÊNCIA DIAGRAMA DE SEQUENCIA Preocupa-se com a ordem temporal em que as mensagens são trocadas,
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 maisCONCEITOS BÁSICOS E MODELO DE PROJETO
CONCEITOS BÁSICOS E MODELO DE PROJETO Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Na aula passada... Abstração Arquitetura Padrões de Projeto Separação por interesses (por afinidades) Modularidade
Leia mais