Software

Ivan Filho
Mind Map by Ivan Filho, updated more than 1 year ago
48
0
0

Description

mapa mental descrevendo conteúdo da máteria de Analise de Software II, ministrada na instituição Unicamp em Limeira

Resource summary

Software
1 Modelagem
1.1 Uml
1.1.1 Diagrama caso de uso
1.1.1.1 Identificação de atores e serviços
1.1.2 Diagrama de Classes
1.1.2.1 Definição da estrutura e das classes
1.1.3 Diagrama de objeto
1.1.3.1 Mostrar valores armazenados pelo objeto
1.1.4 Diagrama de Estrutura Composta
1.1.4.1 Visões de um conjunto de entidades
1.1.5 Diagrama de Sequência
1.1.5.1 Desenrolar dos eventos
1.1.6 Diagrama de Comunicação
1.1.6.1 mostrar como objetos estão interligados e mensagens trocadas sem preocupação de tempo
1.1.7 Diagrama Máquina de Estado
1.1.7.1 Informar mudança de Estado a partir de uma instancia
1.1.8 Diagrama de Atividades
1.1.8.1 Comportamento de objetos entre vários casos de uso
1.1.9 Diagrama de Interação
1.1.9.1 Comportamentos de objetos entr eum uníco caso de uso
1.1.10 Diagrama de Componentes
1.1.10.1 Demonstrar componentes que fazer parte do sistema e seus relacionamentos
1.1.11 Diagrama de Implantação
1.1.11.1 Necessidades físicas do sistema
1.1.12 Diagrama de Pacotes
1.1.12.1 Decompõe o sistema geral em subsistemas que o compõe
1.1.13 Diagrama de Tempo
1.1.13.1 Indica mudança de estado do objeto e o tempo de resposta da mudança
2 Remodelagem
2.1 Reengenharia
2.1.1 Recriar um sistema já projetado
3 Engenharia Reversa
3.1 Entender um código já construido e decompor o mesmo
4 Linguagens
4.1 C++
4.2 Java
4.3 Problemas no desenvolvimento
4.3.1 7 Pecados capitais
4.3.1.1 Pressa
4.3.1.1.1 Qualidade em segundo plano
4.3.1.2 Apatia
4.3.1.2.1 não se importar em resolver problemas conhecidos
4.3.1.3 Mente estreita
4.3.1.3.1 recusa em usar soluções reconhecidamente efetivas
4.3.1.4 Preguiça
4.3.1.4.1 caminho mais "facil" em vez de refletir sobre a decisão
4.3.1.5 Avareza
4.3.1.5.1 Detalhes excessivos, maior complexidade
4.3.1.6 Ignorância
4.3.1.6.1 falha em buscar compreensão
4.3.1.7 Orgulho
4.3.1.7.1 investimento em desenvolver soluções que poderiam ser aproveitadas de outras fontes
5 Coesão
5.1 Alta coesão
5.1.1 Classes se relacionam, sistema unico
5.2 Baixa coesão
5.2.1 Classes se relacionam, mas há divisões em subsistemas
6 Acoplamento
6.1 Alto acoplamento
6.1.1 Relacionamentos demais entre as classes
6.2 Baixo acoplamento
6.2.1 Muito pouco relacionamento entre as classes
7 Problema durante o desenvolvimento
7.1 Contexto e forças
7.1.1 Solução Padrão
7.1.1.1 Padrões de Projeto
7.1.1.1.1 Interface
7.1.1.1.1.1 Adapter
7.1.1.1.1.1.1 Ajustar a interface de uma classe à interface que o cliente espera
7.1.1.1.1.2 Façade
7.1.1.1.1.2.1 Oferecer uma interface única para uma coleção de classes
7.1.1.1.1.3 Composite
7.1.1.1.1.3.1 Definir uma interface que se aplica a objetos individuais ou a grupos de objetos
7.1.1.1.1.4 Bridge
7.1.1.1.1.4.1 Desacoplar uma abstração de sua implementação de forma que as duas possam variar independentemente
7.1.1.1.2 Responsabilidade
7.1.1.1.2.1 Singleton
7.1.1.1.2.1.1 Centralizar responsabilidade em uma única instância da classe
7.1.1.1.2.2 Observer
7.1.1.1.2.2.1 Desacoplar um objeto do conhecimento de quais outros objetos dependem dele
7.1.1.1.2.3 Mediator
7.1.1.1.2.3.1 Centralizar responsabilidade em uma classe que supervisiona como um conjunto de outros objetos interagem
7.1.1.1.2.4 Proxy
7.1.1.1.2.4.1 Deixar um objeto atuar em nome de outro objeto
7.1.1.1.2.5 Chain of responsibility
7.1.1.1.2.5.1 Permitir que uma requisição passe por uma sequência de objetos até encontrar um que possa atendê-la
7.1.1.1.2.6 Flyweight
7.1.1.1.2.6.1 Centralizar responsabilidade em pequenos objetos compartilhados
7.1.1.1.3 Construção
7.1.1.1.3.1 Builder
7.1.1.1.3.1.1 Obter gradualmente a informação necessária para construir um objeto
7.1.1.1.3.2 Factory Method
7.1.1.1.3.2.1 Adiar a decisão sobre qual classe instanciar
7.1.1.1.3.3 Abstract Factory
7.1.1.1.3.3.1 Construir uma família de objetos
7.1.1.1.3.4 Prototype
7.1.1.1.3.4.1 Construir um objeto a partir de exemplo existente
7.1.1.1.3.5 Memento
7.1.1.1.3.5.1 Reconstruir um objeto a partir de informação de estado anteriormente salva
7.1.1.1.4 Comportamento
7.1.1.1.4.1 Command
7.1.1.1.4.1.1 Ecapsular a invocação de um método em um objeto
7.1.1.1.4.2 Template Method
7.1.1.1.4.2.1 Implementar um algoritmo em um método, deixando a definição de alguns passos do algoritmo para subclasses que podem refiná-lo
7.1.1.1.4.3 State
7.1.1.1.4.3.1 Distribuir uma operação de modo que cada classe represente um estado diferente
7.1.1.1.4.4 Interpreter
7.1.1.1.4.4.1 Distribuir uma operação de modo que cada implementação seja aplicável a um tipo diferente de composição
7.1.1.1.4.5 Strategy
7.1.1.1.4.5.1 Encapsular uma operação, tornando as implementações intercabiáveis
7.1.1.1.5 Extensão
7.1.1.1.5.1 Decorator
7.1.1.1.5.1.1 Acrescentar responsabilidades adicionais a um objeto dinamicamente
7.1.1.1.5.2 Iterator
7.1.1.1.5.2.1 Oferecer um modo de acessar uma coleção de instâncias de uma classe
7.1.1.1.5.3 Visitor
7.1.1.1.5.3.1 Acrescentar novas operações a uma classe sem alterar a classe
7.1.2 Solução anti padrão
7.1.2.1 Anti padrões de Projeto
7.1.2.1.1 Arquitetura
7.1.2.1.1.1 Stovepipe Enterprise
7.1.2.1.1.1.1 Sistemas múltiplos em uma empresa são desenvolvidos independentemente em cada nível
7.1.2.1.1.2 Jumble
7.1.2.1.1.2.1 Elementos de design horizontal (comum em todas aplicações) e vertical (dependen de implementações específicas são misturados
7.1.2.1.1.3 Vendor Lock-In
7.1.2.1.1.3.1 custo de mudar de fornecedor do produto ao qual o usuário é dependente para outro é muito alto
7.1.2.1.1.4 Architecture By Implication
7.1.2.1.1.4.1 falta de especificação (documentação) na arquitetura de um software em desenvolvimento, devido a experiências anteriores em construçãod e sistemas parecidos
7.1.2.1.1.5 Design by Committee
7.1.2.1.1.5.1
7.1.2.1.1.6 Swiss army knife
7.1.2.1.1.6.1 tentativa de prover uma classe para diversas necessidades, o designer adiciona um grande numero de assinaturas de interface e, a classe de interface acaba ficando extremamente complexa
7.1.2.1.1.7 Reinventing the wheel
7.1.2.1.1.7.1 necessidade de contornar restrições técnicas, incompatibilidades e licenciamento de softwares presentes em partes ou módulos de terceiros. ao invés de pegar uma solução existente e adequada, adota-se uma solução customizada com desempenho pior que a existente
7.1.2.1.2 Desenvolvimento
7.1.2.1.2.1 Functional Decomposition
7.1.2.1.2.1.1 Possui uma classe que funciona como uma rotina Main, a partir dela várias outras sub-rotinas são chamadas e, para cada sub-rotina, uma classe é implementada, cuja classe serve apenas para efetuar a ação
7.1.2.1.2.2 Poltergeist
7.1.2.1.2.2.1
7.1.2.1.2.3 Boat Anchor
7.1.2.1.2.3.1 parte do código de um sistema ou uma peça de hardware que não tem nenhuma utilidade no projeto atual
7.1.2.1.2.4 Golden Hammer
7.1.2.1.2.4.1 Ferramenta específica que é dominada pela equipe e é utilizada de forma generalista (bom pra tudo)
7.1.2.1.2.5 Dead End
7.1.2.1.2.5.1 Quando tenta incorporar um módulo já pronto porém com incompatibilidade de suporte
7.1.2.1.2.6 Spaghetti Code
7.1.2.1.2.6.1 programa ou sistema que contém muito pouca estrutura de software. Codificação compromete a estrutura de suporte lógico (resultado do código antigo que está sendo modificado ao longo dos anos)
7.1.2.1.2.7 Walking through a minefield
7.1.2.1.2.7.1 prática de lançar um sistema sem que seus erros sejam avaliados corretamente para ganhar tempo
7.1.2.1.2.8 Copy and Paste Programming
7.1.2.1.2.8.1 É a cópia e modificação de um código existente ao invés de criar solução genéricas (identificado pela presença de vários segmentos de código semelhantes intercalados ao longo do projeto)
7.1.2.1.3 Gerencial
7.1.2.1.3.1 Analysis Paralysis
7.1.2.1.3.1.1 Caracterizado por revisões constantes e construção de modelos excessivamente detalhados. Torna o sistema difícil de desenvolver, documentar e testar
7.1.2.1.3.2 Death By Planning
7.1.2.1.3.2.1 Falta de uma abordagem pragmática (objetiva) para o planejamento, cronogramas e captura do processo
7.1.2.1.3.3 Corncob
7.1.2.1.3.3.1 pessoa difícil que causa problemas através de um comportamento destrutivo em relação a equipe ou projeto (alguém discorda dos objetivos ou processos-chave)
Show full summary Hide full summary

Suggestions

Engenharia de Software
Gabriel Alexandre
ERGONOMIA
timEU
01. Eng de software:Fases de Processos da Eng de Software.
Jamil Yahuza Felippe
Quiz - Processo de Software
Adriana Gomes Alves
Etapas de Modelos de Processos de Software
thiagocarvalhojp
Áreas de Conhecimento X Grupos de Processos
Rodrigo Ferreira
Processos de desenvolvimento de software
Thiago Palandrani
Questões Fundamentos Eng de Software
Jamil Yahuza Felippe
Quiz - Processos tradicionais
Adriana Gomes Alves
Engenharia de Software
Marcio Silveira