Wondershare EdrawMind
Galeria de mapas mentais Análise de sistema de informação e mapeamento mental de design
- 14
Análise de sistema de informação e mapeamento mental de design
Este é um mapa mental sobre análise e design de sistemas de informação, incluindo análise de sistema e visão geral de design, levantamento de requisitos de sistema, casos de uso, modelo de domínio, etc.
Editado em 2023-11-14 10:01:51
- Anévrisme intracrânien
Il s'agit d'une carte mentale sur les anévrismes intracrâniens, avec le contenu principal, notamment: le congé, l'évaluation d'admission, les mesures infirmières, les mesures de traitement, les examens auxiliaires, les manifestations cliniques et les définitions.
- Entretien de la comptabilité des coûts
Il s'agit d'une carte mentale sur l'entretien de comptabilité des coûts, le principal contenu comprend: 5. Liste des questions d'entrevue recommandées, 4. Compétences de base pour améliorer le taux de réussite, 3. Questions professionnelles, 2. Questions et réponses de simulation de scénarios, 1. Questions et réponses de capacité professionnelle.
- Méthode de recherche de littérature
Il s'agit d'une carte mentale sur les méthodes de recherche de la littérature, et son contenu principal comprend: 5. Méthode complète, 4. Méthode de traçabilité, 3. Méthode de vérification des points, 2. Méthode de recherche inversée, 1. Méthode de recherche durable.
Análise de sistema de informação e mapeamento mental de design
- Anévrisme intracrânien
Il s'agit d'une carte mentale sur les anévrismes intracrâniens, avec le contenu principal, notamment: le congé, l'évaluation d'admission, les mesures infirmières, les mesures de traitement, les examens auxiliaires, les manifestations cliniques et les définitions.
- Entretien de la comptabilité des coûts
Il s'agit d'une carte mentale sur l'entretien de comptabilité des coûts, le principal contenu comprend: 5. Liste des questions d'entrevue recommandées, 4. Compétences de base pour améliorer le taux de réussite, 3. Questions professionnelles, 2. Questions et réponses de simulation de scénarios, 1. Questions et réponses de capacité professionnelle.
- Méthode de recherche de littérature
Il s'agit d'une carte mentale sur les méthodes de recherche de la littérature, et son contenu principal comprend: 5. Méthode complète, 4. Méthode de traçabilité, 3. Méthode de vérification des points, 2. Méthode de recherche inversée, 1. Méthode de recherche durable.
- Recomendado para você
- Descrição
Sistema de conhecimento do gerente de projetos de sistema de informação (Capítulo 12 Gerenciamento de aquisições do projeto)
- 5
Análise e Design de Sistemas de Informação
chap01 Análise do sistema e visão geral do projeto
Introdução
Este é um conjunto de especificações e orientações para ajudar a desenvolver sistemas de informação
1.1 Desenvolvimento de software e análise e design de sistemas
aplicativo de computador
Um programa de software de computador que executa um conjunto específico de funções em um dispositivo de computação
Faixa média de aplicação
Também chamado de "aplicativo" (app)
Sistema de informação
Um conjunto de componentes inter-relacionados que coletam, processam, armazenam e fornecem informações necessárias para concluir tarefas de negócios.
Escopo mais amplo do que "aplicação"
Inclui software, bancos de dados e processos manuais relacionados
análise de sistema
Atividades que permitem às pessoas compreender e especificar o que um sistema de informação deve realizar
projeto de sistema
Atividades que permitem definir e descrever detalhadamente o sistema que resolve os requisitos
A análise do sistema equivale a desenhar um projeto, enquanto o projeto do sistema é um plano detalhado
1.2 Ciclo de vida de desenvolvimento do sistema
projeto
Uma tarefa planejada que tem começo e fim e produz um determinado resultado
para o desenvolvimento de sistemas de informação
Requer conhecimento de análise de sistemas e ferramentas e técnicas de design de sistemas
SDLC (ciclo de vida de desenvolvimento de sistema), ou seja, ciclo de vida de desenvolvimento de sistema
O ciclo de vida de desenvolvimento de sistemas identifica todo o processo que inclui todas as atividades necessárias para construir, lançar e manter sistemas de informação.
Todas as atividades incluem: análise de sistema, projeto de sistema, programação, teste, manutenção de sistema
seis processos principais
Identifique problemas ou necessidades e obtenha aprovação
Planejar e monitorar projetos
Descubra e entenda os detalhes de um problema ou necessidade
Projetar componentes do sistema que resolvam um problema ou atendam a uma necessidade
Construa, teste e integre componentes do sistema
Conclua o teste do sistema e, em seguida, implante a solução
processo de desenvolvimento de sistema de informação
Uma abordagem prática para desenvolver um sistema de informação específico (também conhecido como metodologia), concluindo o teste do sistema e, em seguida, implantando a solução
Por exemplo
Processo Unificado (UP)
Programação Extrema (XP)
Processo iterativo de desenvolvimento incremental de software Scrum
A maioria dos processos/métodos agora usa desenvolvimento ágil e iterativo
Desenvolvimento ágilAgile development
Um processo de desenvolvimento de sistemas de informação que enfatiza a flexibilidade na antecipação de novos requisitos durante o desenvolvimento
Rápido nos pés; responsivo às mudanças
Nem os usuários nem os membros da equipe entendem completamente os problemas e complexidades do novo sistema, portanto, o planejamento e a execução do projeto devem levar em conta problemas imprevistos.
Desenvolvimento iterativoDesenvolvimento iterativo
Uma abordagem para o desenvolvimento de sistemas em que o sistema "cresce" gradualmente através de múltiplas iterações
Conclua uma pequena parte do sistema (miniprojeto), depois repita o processo para refinar e adicionar mais, depois repita o refinamento e adicione mais até completar
Vantagem
1. Partes do sistema podem ser implantadas rapidamente
2. Retire uma pequena parte para desenvolver primeiro, para que você possa encontrar problemas difíceis no projeto o mais cedo possível
Seis processos principais para iterar em um projeto
A área do círculo representa a carga de trabalho da iteração correspondente neste processo.
Cada iteração realizará vários processos com focos diferentes.
1.5 Tomando o sistema de comércio de OMR como exemplo para introduzir o processo de desenvolvimento
1.5.1 Preparação
Identifique o problema e documente os objetivos do sistema (Processo Principal 1)
Investigação preliminar
Traduzir os resultados em um Documento de Visão do Sistema (SVD)
Obtenha aprovação para iniciar o projeto (Processo Principal 1)
Reúna-se com as principais partes interessadas, incluindo a gestão executiva
Reunir-se com as principais partes interessadas, incluindo a gestão executiva, para tomar decisões e aprovar planos e orçamentos
SVD (documento de visão do sistema)
Um documento de visão do sistema é usado para identificar recursos que beneficiarão a empresa e aqueles que serão incluídos no sistema
Faça isso em duas etapas
Desenvolva uma declaração inicial de benefícios
Adicione estimativas detalhadas de receitas e custos
Geralmente consiste em três partes
Descrição do Problema
Capacidades do sistema
benefícios comerciais
1.5.2 Atividades no primeiro dia
Processo Central 2: Planejando o Projeto
Identifique os principais componentes (áreas funcionais) necessários
Divida o sistema em subsistemas ou componentes
Um subsistema é uma parte do sistema geral
Definir iterações e atribuir cada área funcional às iterações
Planeje uma única iteração
Determine as tarefas necessárias para a iteração
As tarefas identificadas são compiladas e organizadas em uma lista chamada estrutura analítica do projeto (EAP).
Exemplo
Conteúdo da EAP (estrutura de pausas no trabalho)
Base de decomposição (nome)
A base para a decomposição depende dos quatro processos principais a seguir
tempo requerido
Ordem de execução
Medir o tempo necessário e a sequência de execução pode ajudar na construção da rede de trabalho subsequente e no cálculo do caminho crítico (PERT).
O caminho crítico é o caminho mais longo em toda a rede. Os processos pelos quais ele passa precisam ser executados com rigor. Os processos em outros caminhos têm um certo grau de flexibilidade.
Organize e mantenha essas tarefas organizadas por data
Converta a EAP em um cronograma
A vantagem de planejar iterações individuais é que o cronograma é informal e pode ser ajustado para atender a circunstâncias inesperadas.
Desenvolva um rascunho de sequência de trabalho
Benefícios do rascunho de ordem de serviço
1. Ajude a organizar o trabalho em equipe
2. Fornece uma medida para saber se a iteração está indo conforme planejado
3. Se o projeto demorar algum tempo dentro deste cronograma, o líder do projeto poderá perceber que a programação pode exigir mais tempo e recursos e poderá organizar os recursos antecipadamente para ajudar nesta parte do projeto.
Identificar os recursos necessários (pessoas) e organizar o pessoal para executar as tarefas correspondentes
Identifique os membros e as responsabilidades da equipe
1.5.3 Atividades no segundo dia
Faça tarefas preliminares de apuração de fatos para compreender os requisitos. (Processo principal 3)
O Capítulo 2 explicará em detalhes
Desenvolva uma lista preliminar de casos de uso e um diagrama de casos de uso. (Processo principal 3)
Caso de uso
Um caso de uso registra um evento de negócios acionado por um único usuário e a resposta do sistema a esse evento.
Um caso de uso refere-se a um exemplo ou situação de uso do sistema
Por exemplo: Os agentes de compras “usam” este sistema para “consultar fornecedores”
Os casos de uso são geralmente verbos, correspondentes a requisitos/funções
Use exemplo de lista de casos
Exemplo de diagrama de caso de uso
Desenvolva uma lista preliminar de classes e um diagrama de classes. (Processo principal 3)
Classe de objeto
Os sistemas de identificação de classes de objetos precisam compreender e rastrear essas coisas no mundo real.
As classes de objetos precisam salvar informações no sistema
Exemplo de lista de turmas
Exemplo de diagrama de classes
Este é um diagrama de classes preliminar, portanto, existem apenas propriedades (recursos estáticos)
O diagrama de classes de design terá tipos de dados de atributos e métodos de classe, etc.
O diagrama acima é desenvolvido usando a Linguagem de Modelagem Unificada UML
1.5.4 Atividades no terceiro dia
Conduza uma investigação aprofundada dos fatos para aprender os detalhes. (Processo principal 3)
Entenda e documente o fluxo de trabalho detalhado para cada caso de uso. (Processo principal 3)
Desenvolva descrições de casos de uso e diagramas de fluxo de trabalho
Aqui estão duas maneiras de documentar detalhes do caso de uso
O desenvolvimento de diagramas de fluxo de trabalho requer o uso de diagramas de atividades, que são diagramas em UML
Exemplo de diagrama de fluxo de trabalho
As formas ovais na figura representam tarefas, os losangos representam pontos de decisão, as setas representam o fluxo de sequência e as setas cruzando a linha central representam a interação entre o usuário e o sistema.
Defina a experiência do usuário com telas e relatórios. (Processo principal 3 e 4)
Definir layout da tela
1.5.5 Atividades no quarto dia
Projete a estrutura do banco de dados (esquema). (Processo principal 4)
desenho de mesa
Palavras-chave e identificadores de índice
Tipo de Propriedade
integridade referencial
Exemplo de esquema de banco de dados
Projete a estrutura de alto nível do sistema. (Processo principal 4)
Projeto arquitetônico geral
Definir diagrama de classes de projeto preliminar
Exemplo de diagrama de classes de projeto preliminar
As classes de design incluem as variáveis de nível de classe exigidas pela classe, que também mostram os nomes dos métodos importantes em cada classe. Os últimos elementos em um diagrama de classes de design são setas, que mostram quais classes têm acesso a métodos de quais outras classes.
Projeto de arquitetura de subsistema
1.5.6 Atividades no quinto dia
Continue com o projeto detalhado (CP4)
Realizar programação e testes individuais (CP5)
Design e programação não se trata de projetar tudo e depois programar, mas de projetar uma peça, programar, depois projetar uma peça e depois programar novamente.
1.5.7 Atividades no sexto dia
Teste completo do sistema (CP6)
Teste funcional geral do sistema
Testes de aceitação do usuário
Possível implantação de sistemas parciais (CP6)
1.5.8 Revisão da primeira iteração
1.6 Introdução ao conteúdo subsequente
1.6.1 Parte Um Introdução ao Desenvolvimento de Sistemas
Capítulo um
1.6.2 Parte 2 Atividades de Análise do Sistema
Capítulos 2, 3, 4 e 5
1.6.3 Parte 3 Atividades de Design de Sistema
Capítulo Seis e Sete
1.6.4 Parte 4 Projetos e Gerenciamento de Projetos
Capítulo 8 e 9
1.6.5 Parte 5 Conceitos Avançados e Conceitos de Implantação
Capítulo 10, 11, 12
cap02 Pesquisa de requisitos do sistema
2.1 Introdução
Neste capítulo, começamos a expandir o escopo e os detalhes do processo SDLC para cobrir uma gama mais ampla de conceitos, ferramentas e técnicas. Embora este capítulo se concentre nas atividades de análise de sistemas (o terceiro processo principal listado), os capítulos seguintes discutirão detalhadamente os modelos desenvolvidos durante essas atividades de análise de sistemas. Os capítulos subsequentes expandem a discussão de outros processos centrais do SDLC.
2.2CSMS (Sistema Abrangente de Vendas e Marketing) para RMO
2.2.1 Sistema de informação e arquitetura existentes do RMO
A arquitetura é dividida em dois tipos
arquitetura tecnológica arquitetura tecnológica
A arquitetura tecnológica descreve o conjunto de hardware de computação, hardware e topologia de rede e software de sistema usado por uma organização (como sistemas operacionais e sistemas de gerenciamento de banco de dados).
arquitetura de aplicação arquitetura de aplicação
A arquitetura de aplicativos descreve como os recursos de software são organizados e estruturados para implementar os sistemas de informação de uma organização. Descreve a organização do software em módulos e subsistemas, incluindo tecnologias de suporte (como linguagens de programação e ambientes de desenvolvimento), abordagens arquitetônicas (como arquitetura orientada a serviços) e tecnologias de interface de usuário (como telas de computação móvel, telas sensíveis ao toque tecnologia e reconhecimento de fala).
2.1.2 Novo CSMS
O novo sistema integrado de vendas e marketing terá quatro subsistemas
Subsistema de vendas
Subsistema de implementação de pedidos
Subsistema de conta do cliente
Subsistema de marketing
2.3 Atividades de análise do sistema
Existem cinco partes principais
2.3.1 Colete informações detalhadas
Entrevistas, questionários, documentação, observação de processos de negócios, pesquisa de fornecedores, opiniões e sugestões
2.3.2 Definir requisitos
Modelagem de requisitos funcionais e não funcionais
2.3.3 Priorização de requisitos
2.3.4 Desenvolver caixas de diálogo de interface de usuário
O processo de interação entre os usuários e o sistema
2.3.5 Avaliar necessidades com os usuários
Envolvimento do usuário, feedback, adaptação às mudanças
2.4 O que é demanda
Os requisitos do sistema são todas as atividades que o novo sistema deve realizar ou suportar e as restrições que o novo sistema deve satisfazer.
Os requisitos do sistema são divididos em
requisitos funcionais
Os requisitos funcionais são as atividades que o sistema deve realizar (por exemplo, o negócio ao qual o sistema será aplicado).
Requer que o usuário execute
requisitos não Funcionais
Requisitos não funcionais são características que vão além das atividades que o sistema deve executar ou suportar.
Como indicadores de desempenho, restrições (ferramentas de desenvolvimento, formatos de dados, etc.)
Você pode usar o FURPS para simplesmente dividir os requisitos
funcionalidade funcional
disponibilidade de usabilidade
Confiabilidade
Desempenho
Segurança
Outros, como condições restritivas
requisitos não Funcionais
2.5 Modelos e Modelagem
Modelo
Um modelo é uma representação de algum aspecto do sistema que está sendo construído.
Tipo de modelo
modelo de texto
relatórios, documentos
modelo gráfico
Diagrama esquemático
modelo matemático
Fórmula
linguagem de modelagem
O desenvolvimento de muitos modelos gráficos é implementado através de UML (Linguagem de Modelagem Indefinida)
UML é um conjunto de construções e símbolos de modelo padrão definidos pelo Object Management Group, uma organização sem fins lucrativos.
2.6 Partes Interessadas
As partes interessadas são todos aqueles que têm interesse no sucesso da implementação do sistema.
Classificação das partes interessadas
partes interessadas internas
As partes interessadas internas são pessoas dentro da organização que interagem com o sistema ou têm um interesse significativo na sua operação ou sucesso.
Partes interessadas externas
As partes interessadas externas são aquelas que estão fora do controle e influência da organização,
partes interessadas operacionais
As partes interessadas operacionais são pessoas que interagem frequentemente com o sistema no seu trabalho ou na vida.
Exemplos: contadores interagindo com sistemas de contabilidade ou faturamento, trabalhadores de fábricas interagindo com sistemas de programação de produção, clientes interagindo com lojas na Internet e pacientes interagindo com sites de saúde, páginas do Facebook ou feeds de notícias do Twitter.
Gerenciar as partes interessadas
As partes interessadas da gestão são aquelas que não interagem diretamente com o sistema, mas utilizam a informação produzida pelo sistema ou têm um interesse financeiro significativo ou outro no seu funcionamento e sucesso.
Por exemplo: a alta administração e o conselho de administração de uma organização, reguladores e autoridades fiscais.
Dois tipos de partes interessadas importantes
Cliente: a pessoa que fornece suporte financeiro
Pessoal de suporte técnico do sistema
2.7 Tecnologia de coleta de informações
As tecnologias de coleta de informações incluem
2.7.1 Realizar entrevistas com usuários e outras partes interessadas
Analistas de sistemas são necessários
Prepare perguntas detalhadas
assunto da pergunta
Qual deve ser o processo de negócios?
Como funcionam os processos de negócios
Quais informações são necessárias
Tipo de pergunta
perguntas abertas
perguntas fechadas
Objeto de pergunta: sistema antigo ou novo sistema
Conheça usuários individuais ou grupos de usuários
Obtenha e discuta respostas a perguntas
gravar resposta
Acompanhe as informações para usar em entrevistas futuras
2.7.2 Distribuir e coletar questionários
Três tipos de perguntas
perguntas fechadas
Veja os problemas de formato
perguntas abertas
2.7.3 Verifique entrada, saída e processo
Existem duas fontes de entrada, saída e processos
Registros de negócios e descrições de processos dentro da organização
De fora da organização – organizações profissionais e outras empresas do setor
Verifique a documentação de processamento existente
2.7.4 Observar e registrar processos de negócios
Isso ajudará você a entender a função do negócio
2.7.5 Pesquisar soluções de fornecedores
Três benefícios e um perigo
1. Estudar essas soluções pode ajudar os usuários a pensar melhor sobre como administrar melhor as funções de negócios
2. Algumas soluções já são de primeira linha e é difícil acompanhar a tendência sem realizar pesquisas.
3. Comprar uma solução é menos arriscado e mais barato do que pesquisar uma
Perigo: Correr para comprar uma solução sem investigar todas as necessidades do sistema
2.7.6 Coletar comentários de usuários ativos
2.8 Use o diagrama de atividades para registrar o fluxo de trabalho
Fluxo de trabalho
Um fluxo de trabalho é uma série de etapas de processamento que tratam completamente de uma transação comercial ou solicitação de cliente.
diagrama de atividades
Um diagrama de atividades descreve diversas atividades do usuário (ou sistema), as pessoas que realizam cada atividade e o fluxo sequencial dessas atividades.
Símbolos e explicações
As reticências representam diversas atividades no fluxo de trabalho. As setas de ligação indicam a sequência entre as atividades. Os círculos pretos representam o início e o fim do fluxo de trabalho. O diamante é um ponto de decisão no qual o processo seguirá um caminho ou outro. A linha sólida espessa é uma barra de sincronização que pode dividir um caminho em vários caminhos simultâneos ou recombinar caminhos simultâneos. O título da raia representa o agente que realiza a atividade. Como geralmente há diferentes agentes (ou seja, pessoas) em um fluxo de trabalho executando diferentes etapas do processo de fluxo de trabalho, os símbolos da raia dividem as atividades do fluxo de trabalho em grupos, mostrando qual agente executa qual atividade.
caso de uso chap03
3.1 Introdução
Assim como os Capítulos 4 e 5, este capítulo apresenta técnicas para documentar requisitos funcionais através da criação de vários modelos.
Um caso de uso é uma atividade que um sistema executa, geralmente em resposta a uma solicitação do usuário.
Os casos de uso definem requisitos funcionais
Os analistas decompõem o sistema em um conjunto de casos de uso (decomposição funcional)
Os casos de uso geralmente recebem nomes de verbos ou gerúndios
3.2 Casos de uso e objetivos do usuário
Uma técnica para definir casos de uso é a técnica de objetivos do usuário, que pede aos usuários que descrevam seus objetivos ao usar um sistema novo ou atualizado.
Dividido em oito etapas
Identifique todos os usuários potenciais do novo sistema
Categorize usuários potenciais com base em funções funcionais (por exemplo, transporte, marketing, vendas)
Classifique ainda mais os usuários potenciais por nível organizacional (por exemplo, operações, gerenciamento, executivo)
Para cada tipo de usuário, visite-os e encontre uma lista de objetivos específicos que terão ao utilizar o novo sistema (objetivos atuais e funcionalidades inovadoras que agregam valor)
Crie uma lista preliminar de casos de uso organizados por tipo de usuário
Encontre cópias com nomes de casos de uso semelhantes e resolva inconsistências
Determine onde diferentes tipos de usuários exigem os mesmos casos de uso
Revise a lista preenchida com cada tipo de usuário e partes interessadas
Geralmente apenas eventos com requisitos funcionais são considerados
As técnicas de segmentação de usuários são simples, mas comumente usadas
3.3 Decomposição de casos de uso e eventos
A tecnologia de decomposição de eventos é a tecnologia mais abrangente para identificar casos de uso
A técnica de decomposição de eventos determina primeiro todos os eventos de negócios que farão com que o sistema de informação responda, e cada evento levará a um caso de uso. Começar com eventos de negócios ajuda os analistas a definir cada caso de uso no nível certo de detalhe
Usado para determinar o nível apropriado de detalhe para um caso de uso é o Processo de Negócios Essencial (EBP)
EBP é uma tarefa executada por uma pessoa em um só lugar para responder a eventos de negócios, agregar valor comercial mensurável e colocar o sistema e seus dados em um estado estável e consistente.
Cada EBP responde a um evento de negócios quando ele ocorre
3.3.1 Tecnologia de decomposição de eventos
evento
Os eventos ocorrem em um horário e local específicos, podem ser descritos e devem ser lembrados pelo sistema
3.3.2 Tipos de eventos
eventos externos
Eventos externos são eventos que ocorrem fora do sistema, geralmente iniciados por agentes ou atores externos.
Agentes (ou atores) externos são indivíduos ou unidades organizacionais que fornecem ou recebem dados ao sistema.
Por exemplo
Vários processos de negócios, como fazer pedidos de usuários, etc.
Eventos externos são geralmente usados para responder a solicitações de usuários (atores) e ocorrem em ambientes de interação humano-computador.
Evento cronometrado/tempo temporário
Um evento que ocorre como resultado de atingir um determinado ponto no tempo.
Por exemplo
Envie regularmente relatórios estatísticos, etc.
Eventos temporários ocorrem dentro do sistema
evento de status
Os eventos de status ocorrem quando ocorre um evento no sistema que aciona um requisito de processamento.
Causado quando o status muda
Geralmente, são requisitos não funcionais e nem sempre são considerados.
3.3.3 Definir eventos
Evento/Pré-condição/Resposta
Os analistas devem considerar uma sequência de eventos e então identificar os eventos que realmente afetam o sistema.
sequência de eventos
É útil rastrear uma série de eventos que ocorreram a uma entidade ou ator externo específico
Eventos de dependência de tecnologia e controle do sistema
Às vezes, os analistas estão preocupados com eventos que são importantes para o sistema, mas não estão diretamente relacionados aos usuários ou às transações. Esses eventos normalmente envolvem escolhas de design ou controles de sistema. Os analistas devem ignorar temporariamente esses eventos durante a análise.
Os controles do sistema são verificações ou procedimentos de segurança projetados para proteger a integridade de um sistema
Backup de dados, login, etc.
Durante a fase de análise usaremos suposições técnicas ideais
A hipótese da tecnologia perfeita afirma que os eventos só ocorrem quando o sistema precisa responder em condições perfeitas (por exemplo, o dispositivo nunca falha, o poder de processamento e armazenamento é ilimitado e as pessoas que operam o sistema são completamente honestas e nunca cometem erros). incluídos no processo de análise.
3.3.4 Use tecnologia de decomposição de eventos
1. Considere eventos externos no ambiente do sistema que exigem resposta do sistema
2. Para cada evento externo, identifique e nomeie o caso de uso exigido pelo sistema.
3. Use uma lista de verificação para considerar eventos de tempo que exigem uma resposta do sistema.
4. Para cada evento temporal, identifique e nomeie os casos de uso exigidos pelo sistema e, em seguida, estabeleça o ponto no tempo que aciona o caso de uso.
5. Considere os eventos de estado aos quais o sistema pode responder, especialmente se for um sistema em tempo real onde alterações de estado interno ou de dispositivo acionam casos de uso.
6. Para cada evento de estado, identifique e nomeie o caso de uso exigido pelo sistema e defina a mudança de estado.
7. Após definir eventos e casos de uso, verifique se eles exigem suposições técnicas perfeitas. Não inclua eventos que envolvam controles do sistema como login, logout, alteração de senha e backup ou recuperação do banco de dados, pois estes são colocados como controles do sistema.
3.4 Casos de uso e CRUD
Outra tecnologia importante para validar e refinar casos de uso é a tecnologia CRUD.
CRUD significa
Criar
Ler ler
Atualizar, atualizar
Excluir, excluir
Estas são operações relacionadas ao gerenciamento de banco de dados
As técnicas CRUD são mais úteis quando usadas em conjunto com técnicas de segmentação de usuários como verificação cruzada. Em vez de usá-lo diretamente como um método para identificar casos de uso, pode fazer com que os casos de uso não rastreiem muito bem o processo de negócios.
Pode verificar se há algum tipo de caso de uso ausente
Etapas da tecnologia CRUD
1. Identifique todas as entidades de dados ou classes de domínio envolvidas no novo sistema.
2. Para cada tipo de dados (entidade de dados ou classe de domínio), verifique se você identificou casos de uso para criar novas instâncias, atualizar instâncias existentes, ler ou relatar valores de instância e excluir (arquivar) instâncias.
3. Se um caso de uso obrigatório for ignorado, adicione um novo caso de uso e identifique as partes interessadas.
4. Para aplicativos integrados, certifique-se de que esteja claro qual aplicativo é responsável por adicionar e manter dados e qual sistema usa apenas os dados.
3.6 Diagrama de caso de uso
Diagramas de casos de uso são modelos UML usados para exibir graficamente casos de uso e seu relacionamento com os usuários.
3.6.1 Casos de uso, atores e símbolos
Implícitos na maioria dos casos de uso estão as pessoas que usam o sistema, às quais até agora nos referimos como usuários. Na UML, essa pessoa é chamada de ator. Os atores geralmente estão fora dos limites da automação
No diagrama de casos de uso, o símbolo humano representa o ator, o oval representa o caso de uso, a borda retangular representa o limite da automação e a conexão entre o caso de uso e o ator representa qual ator participa de qual caso de uso.
Exemplo
Não só existem relacionamentos entre casos de uso e atores, mas também pode haver relacionamentos entre casos de uso.
Esta é uma dependência entre casos de uso e vem em duas formas Use setas tracejadas e << >> para indicar
<<incluir>>
Pode ser entendido como um relacionamento de uso, que se refere ao uso de um caso de uso em outro caso de uso. O caso de uso apontado pela seta é o caso de uso utilizado (dependente). Este relacionamento exige que um caso de uso seja usado em outro caso de uso.
<<estendido>>
Esse relacionamento indica que um caso de uso pode usar outro caso de uso. Nesse relacionamento, haverá algo chamado ponto de extensão. Por exemplo, em um sistema de gerenciamento de biblioteca, o caso de devolução de livros pode envolver multas (tempo limite, etc.). Este é o relacionamento estendido.
A conexão entre os dois é que ambos são relacionamentos entre casos de uso, e ambos significam usar outro caso de uso em um caso de uso. A diferença entre os dois é que incluir significa que outro UC será definitivamente usado, enquanto estendido requer o julgamento da extensão; ponto antes de decidir usar ou não
modelo de domínio chap04
4.1 Introdução
Conceitos principais: coisas no domínio do problema do usuário do sistema
4.2 Coisas no domínio do problema
O domínio do problema refere-se à área específica de negócios do usuário incluída no novo sistema.
Classes ou entidades de domínio são o que os usuários finais precisam para trabalhar no estúdio. Geralmente são chamadas de "coisas" no domínio do problema do sistema.
Por exemplo
produtos, pedidos, clientes
4.2.1 Método 1 para definir coisas no domínio do problema - método de brainstorming
1. Identifique um usuário e um conjunto de casos de uso.
2. Faça um brainstorming com os usuários para identificar os itens envolvidos na execução do caso de uso, ou seja, os itens sobre os quais o sistema deve capturar informações.
3. Use tipos de coisas (categorias) para fazer perguntas sistematicamente sobre coisas potenciais, por exemplo: Você armazena informações sobre alguma coisa tangível? Há algum local envolvido? Quais papéis você precisa lembrar?
4. Continue a trabalhar com diversos usuários e partes interessadas para expandir a lista de brainstorming.
5. Combine os resultados, elimine quaisquer duplicatas e compile uma lista inicial.
4.2.2 Método 2 de definição de coisas no domínio do problema - tecnologia substantiva
Liste todos os substantivos mencionados pelos usuários Os substantivos usados para descrever eventos, casos de uso ou atores são coisas potenciais.
etapa
1. Identifique todos os substantivos usando casos de uso, atores e outras informações sobre o sistema (incluindo entradas e saídas).
2. Usando sistemas existentes, procedimentos atuais e outras informações de relatórios ou formulários atuais, adicione itens ou categorias de informações necessárias. Alguns desses itens podem ser coisas adicionais e alguns podem ser informações mais específicas (chamadas atributos) sobre coisas que você já identifica. Refine a lista e registre as hipóteses ou questões que deseja explorar.
3. À medida que esta lista de substantivos for construída, você precisará refiná-la.
Faça as seguintes perguntas para cada substantivo para ajudá-lo a decidir se ele deve ser incluído:
É algo único que o sistema precisa saber?
Está dentro do escopo do sistema que estou desenvolvendo?
O sistema precisa lembrar mais de um dos itens acima?
Faça as seguintes perguntas sobre cada substantivo para decidir se ele deve ser excluído:
É realmente sinônimo de outra coisa que identifiquei?
É realmente apenas a saída do sistema com base em outras informações que identifiquei?
É realmente apenas uma entrada que resulta no registro de outras informações que identifiquei?
Faça as seguintes perguntas sobre cada substantivo para decidir se ele deve ser estudado:
É possível que sejam informações específicas (propriedade) sobre outras coisas que identifiquei?
Se as suposições mudarem, posso precisar disso?
4. Crie uma lista mestra de todos os substantivos identificados e indique se cada substantivo deve ser incluído, excluído ou estudado mais detalhadamente.
5. Revise a lista com usuários, partes interessadas e membros da equipe e, em seguida, refine a lista de itens no domínio do problema.
Exemplo
4.2.3 Propriedades das coisas
A maioria dos sistemas armazena algumas informações específicas sobre transações chamadas atributos
Um atributo que identifica algo exclusivamente é chamado de identificador ou palavra-chave (chave/código)
Atributos compostos são compostos por vários atributos relacionados, como endereço, nome completo, etc.
4.2.4 Relações entre coisas
Associação refere-se à relação que ocorre naturalmente entre certas coisas.
Na UML, existem aproximadamente quatro tipos de relacionamentos entre coisas
Associação
generalização de geração
dependênciadependência
implemento
detalhes associados
tem um nome
Existe uma direção, e a coisa apontada pela seta não pode ver a outra (ou seja, a outra depende da coisa apontada pela seta, e a coisa apontada muda para a outra, mas vice-versa não tem efeito)
Por exemplo, A->B é chamado de A dependente de B.
Associação é multiplicidade, ou seja, a relação quantitativa entre uma coisa e outra coisa
exemplo
Existem restrições de cardinalidade entre associações
elemento associado
Uma associação consiste em vários tipos diferentes de coisas, e o número dessas coisas é a aridade da associação
Cliente e pedido, relacionamento binário
Associação entre coisas semelhantes, um elemento
Três ou mais tipos diferentes de coisas estão relacionadas, múltiplas
4.3 Diagrama Entidade-Contato
Este é um modelo para modelagem de banco de dados
Os retângulos representam entidades e as linhas que conectam os retângulos representam conexões entre entidades.
representação simbólica
Apenas as linhas verticais são truncadas para representar que existe e apenas um
As linhas verticais são cortadas e circuladas para representar 0 ou 1
Um círculo com uma linha cruzada indica 0 ou mais
As linhas verticais cortadas e as linhas bifurcadas representam uma ou mais
A direção correspondente ao número é de sem sinal para assinado
Nos atributos da entidade, o código primário (identificador) é colocado na primeira linha, e PK é marcado para indicar que se trata do código primário.
Exemplo
Um cliente corresponde a 0 para vários pedidos; um pedido corresponde a um e apenas um cliente;
4.4 Diagrama de classes do modelo de domínio
A classe de coisas em questão é chamada de classe de domínio
Na UML, o diagrama de classes é usado para exibir as classes de objetos do sistema
Diagrama de classes do modelo de domínio
Usado para exibir coisas no domínio do problema do usuário
Diagrama de classes de design
para projeto
representação simbólica
Em um diagrama de classes, os retângulos representam classes e as linhas retas que conectam os retângulos representam relacionamentos entre classes.
O retângulo tem duas partes (diagrama de classes do modelo de domínio, diagrama de classes de design consiste em três partes: nome da classe, atributos, métodos), a parte superior é o nome da classe e a parte inferior são os atributos da classe
Os nomes de classes e nomes de atributos usam a nomenclatura camel case. A primeira letra do nome da classe é maiúscula e a primeira letra do nome do atributo é minúscula.
4.4.1 Notação do diagrama de classes do modelo de domínio
símbolo de multiplicidade
Representa o número de relacionamentos entre instâncias de classe, semelhante à multiplicidade de diagramas de relacionamento de entidade
Exemplo
A multiplicidade aqui é semelhante à cardinalidade de mapeamento do diagrama entidade-relacionamento.
Aplicativo de diagrama de classes de domínio específico
Este é um diagrama de classes de modelo de domínio para seleção de cursos de alunos. Um curso pode ter de 0 a várias seções, mas uma seção só pode pertencer e deve pertencer a um curso e as seções têm um relacionamento muitos para muitos e ambos podem ser; zero Existe turma de associação entre alunos e cursos, marcada com linha pontilhada, com atributo nota;
4.4.2 Questões mais complexas relacionadas às classes de objetos
Existem três tipos de relacionamentos em classes de domínio
Associação
Geração de generalização/especialização
A base da relação generalização/especialização é que as pessoas classificam as coisas com base em semelhanças e diferenças.
A relação generalização/especialização é usada para estruturar ou ordenar essas coisas do mais geral para o mais específico.
Cada classe na hierarquia pode ter uma classe mais geral acima dela, chamada superclasse.
Uma classe pode ter uma classe mais especializada abaixo dela, chamada subclasse.
A herança permite que as subclasses compartilhem características de sua superclasse.
Use uma seta triangular para apontar para a superclasse
Exemplo
Use itálico para rotular classes abstratas
Classes abstratas não podem ser instanciadas e só podem ser herdadas
Existe também uma classe concreta, que é uma classe que pode ter objetos de instância.
As superclasses às vezes são concretas ou abstratas
Parte inteira
O relacionamento global/parte é usado para expressar o relacionamento entre uma classe e outras classes contidas nesta classe.
polimerização
Em um relacionamento de agregação, os componentes podem existir independentemente
Use diamantes vazados para representar
combinação
Numa relação combinada, cada parte não pode existir independentemente uma vez que esteja relacionada.
Use um losango sólido para representar
Capítulo05 Extensão do modelo de requisitos
5.2 Descrição do caso de uso
As descrições dos casos de uso descrevem os detalhes de cada caso de uso.
Descrição simples do caso de uso
Adequado para cenários únicos e menos exceções
Exemplo
Descrição do caso de uso totalmente desenvolvida
Para alguns casos de uso mais complexos, é necessária uma descrição de caso de uso totalmente expandida.
Modelo padrão
Usar nome do caso
Cenários de casos de uso
evento desencadeador
Descrição rápida
participantes
Outros casos de uso associados a ele e como está associado
Partes interessadas
Pré-requisitos
Os pré-requisitos determinam o estado do sistema quando um caso de uso começa, incluindo objetos que já devem existir, informações que devem estar disponíveis e até mesmo condições para os atores antes do início do caso de uso.
Condições subsequentes
As pós-condições determinam o que deve ser verdadeiro quando o caso de uso for concluído. Mais importante ainda, eles indicam quais novos objetos o caso de uso cria ou atualiza e como os objetos precisam ser relacionados.
fluxo de atividade
Fluxo de atividades incluindo participantes (usuários) e sistema
situação anormal
O fluxo de atividades para cada caso de uso pode ser muito diferente, dependendo do ator que invoca o caso de uso. Os diferentes fluxos de atividades são chamados de cenários, também conhecidos como instâncias de casos de uso;
5.3 Diagrama de atividades de caso de uso
Uma maneira de registrar casos de uso é usar diagramas de atividades. Aprendemos a usar diagramas de atividades para construir fluxos de trabalho no Capítulo 2. Usaremos diagramas de atividades aqui para registrar o fluxo de atividades de casos de uso.
Exemplo
Este diagrama de atividades mostra o fluxo de atividades do registro de caso de uso de registro de cliente.
5.4 Diagrama de sequência do sistema SSD
O Diagrama de Sequência do Sistema é usado para descrever o fluxo de informações que entra e sai de um sistema de automação
Use símbolos humanos para representar atores de casos de uso e bordas retangulares para representar limites de automação
O retângulo está marcado: sistema (com dois pontos), indicando o sistema automatizado
Há uma linha pontilhada abaixo dos participantes e do sistema, chamada linha de vida, que representa o ciclo de vida dos participantes e do sistema, e o tempo flui de cima para baixo.
Existe o envio e recebimento de mensagens entre os participantes e a tábua de salvação do sistema
O envio de mensagens é representado por uma linha contínua, com o direcionamento do participante para o sistema
As mensagens recebidas são representadas por linhas tracejadas com direção do sistema para o participante
Representação simbólica completa da mensagem
(*)[Condição Verdadeira/Falsa] Valor de retorno:=Nome da mensagem (lista de parâmetros)
* indica ciclo
[] representa as condições verdadeiras e falsas. Se o interior for verdadeiro, a mensagem será enviada, caso contrário não será enviada.
O nome da mensagem é uma descrição da mensagem enviada
A lista de parâmetros é a informação a ser passada
Além disso, existem algumas estruturas alternativas
alteração de loop
Se várias mensagens forem enviadas e recebidas em loop, talvez seja melhor usar uma estrutura alternativa.
A moldura alternativa é usar uma moldura retangular para selecionar a parte a ser loopada e um loop expresso para todos os itens no canto superior esquerdo
selecione alterar
O quadro alternativo de seleção é usado em conjunto com outro. Use um quadro retangular para selecionar a área de seleção. Use linhas pontilhadas para distinguir as mensagens enviadas em diferentes circunstâncias e marque-as separadamente na parte final do envio da mensagem.
5.4.2 Desenvolver SSD
1. Confirme a mensagem de entrada
2. Use símbolos de mensagem para descrever informações transmitidas de fora para o sistema
3. Adicione condições específicas na mensagem de entrada, incluindo loops e condições verdadeiro/falso
4. Confirme e adicione mensagem de retorno
5.5 diagrama de máquina de estado diagrama de máquina de estado
O estado de um objeto é uma condição que ocorre durante seu tempo de vida quando certas condições são atendidas, certas ações são executadas ou algum evento é aguardado.
A transição de estado é a atividade de um objeto passando de um estado para outro.
função de transição de estado
Nome da conversão (parâmetro,...) [condição de julgamento]/descrição do comportamento
Uma expressão de ação representa algum processo que deve ocorrer antes que a transição seja concluída e o objeto atinja o estado alvo.
Uma condição é um qualificador ou teste para uma transição; é simplesmente uma condição verdadeira/falsa que deve ser atendida antes que a transição possa ser acionada.
5.5.1 Estado composto e estado simultâneo
Estar em vários estados ao mesmo tempo é chamado de simultaneidade ou estados simultâneos.
Representado por caminhos simultâneos semelhantes aos diagramas de atividades, um caminho é um conjunto ordenado de transições de estado interconectadas.
Aninhe estados em outros estados de nível superior. Esses estados de nível superior são chamados de estados compostos.
Os estados compostos são representados por estados de alto nível aninhados em estados de baixo nível
Exemplo
Quando a impressora está ligada (estado composto), ela possui dois caminhos simultâneos, ou seja, a parte da bandeja de papel e a parte de impressão. As duas partes são independentes quando o botão liga/desliga é ligado; pressionado, ele desliga. Não há restrições.
5.5.2 Regras para desenvolvimento de diagramas de máquinas de estados
Visualize o diagrama de classes e selecione as classes que podem exigir estado
Para cada classe selecionada no grupo, liste todas as condições de status que você pode determinar
Começa a construir um fragmento de diagrama de máquina de estado identificando as transições que fazem com que um objeto saia do estado identificado
Organize essas combinações de transição de estado na ordem correta
Verifique esses caminhos e procure caminhos simultâneos independentes
Encontre outras conversões
Expanda cada transição com eventos de mensagem, condições de proteção e expressões de ação apropriados
Verifique e teste cada diagrama de máquina de estado
5.6 Integração de modelos de demanda
A relação entre vários modelos de demanda
Diagrama de casos de uso
Descrição do caso de uso
diagrama de atividades
SSD
Diagrama de classes do modelo de domínio
Diagrama de máquina de estado
O relacionamento é descrito pela figura a seguir
A seta aponta na direção do item dependente para o item dependente
As linhas sólidas representam dependências primárias, as linhas pontilhadas representam dependências secundárias e algumas setas são bidirecionais, indicando influência mútua.
cap06 Pontos básicos de design e atividades de design
6.1 Introdução
Na fase de análise discutiremos principalmente o que o sistema faz (como requisitos); enquanto na fase de design discutiremos principalmente como o sistema atinge esses requisitos;
A entrada e a saída do projeto do sistema não são a entrada e a saída do sistema: a entrada do projeto do sistema é o resultado da análise do sistema, ou seja, os requisitos e modelos relacionados, enquanto a saída do projeto do sistema é uma solução mais detalhada
6.2 Elementos de projeto
6.2.1 O que é projeto de sistema?
O design do sistema é um processo de ponte entre a análise e a implementação do sistema com o objetivo de definir, organizar e construir os componentes da solução final como um modelo para a construção.
6.2.2 Principais componentes e níveis de projeto
Componentes principais
design Ambiental
Descreve as redes, hardware, etc. que conectam o sistema
design de aplicativo
Programa de computador
Design da interface do usuário
Telas, relatórios e controles definidos para entrada e saída
Projeto de banco de dados
Estrutura do banco de dados
Design de interface do sistema
Descreve a comunicação com outros sistemas
Projeto de Segurança e Controle
dois níveis
Projeto de arquitetura
Esclareça toda a estrutura e forma da solução, que é o desenho amplo da estrutura geral do sistema
Também chamado de design geral ou design conceitual
projeto detalhado
Inclui detalhes de programação específicos
Exemplo
Design por caso de uso
Projeto de banco de dados
Design da interface do usuário e interface do sistema
Projeto de Segurança e Controle
6.3 Entrada e saída do projeto do sistema
Converter informações como modelos de análise e documentos obtidos da análise do sistema em um modelo que representa o sistema de solução
Modelo analítico
Diagrama de classes
Diagrama de caso de uso UCD
Diagrama de sequência do sistema SSD
Descrição do caso de uso
Diagrama de máquina de estado
diagrama de atividades
modelo de projeto
Mapa do pacote
Gráfico de nó e localização
Diagrama de classes de design
Fluxograma
Esquema de banco de dados
Interface de usuário e sistema
Controle de segurança do sistema
Diagrama de colaboração
6.4 Atividades de projeto
As atividades de design são o design dos seis componentes acima. Cada atividade de design tem questões-chave correspondentes.
design Ambiental
Detalhamos o ambiente em que o software será executado e todas as diversas opções?
Arquitetura de aplicativos e design de software
Detalhamos todos os elementos do software e como cada caso de uso é executado?
Design da interface do usuário
Detalhamos como esse sistema se comunicará com todos os outros sistemas dentro e fora da organização?
Projeto de interface do sistema
Detalhamos como os usuários irão interagir com o sistema para realizar todas as suas tarefas [casos de uso]?
Projeto de banco de dados
Especificamos todos os requisitos de armazenamento de informações, incluindo todos os elementos do esquema?
Projeto de Segurança e Controle
Detalhamos todos os elementos necessários para garantir que os sistemas e dados estejam seguros e protegidos?
6.4.1 Ambiente de projeto
O ambiente é toda a tecnologia necessária para suportar uma aplicação de software
Servidor, computador desktop
dispositivos móveis, sistemas operacionais
Capacidade de comunicação, capacidade de entrada e saída
Chamamos isso de arquitetura técnica no Capítulo 2
6.4.2 Projetar arquitetura e software de aplicativos
Divida o sistema em subsistemas
Definir arquitetura de software (projeto arquitetônico)
Arquitetura MVC de três camadas, etc.
Design detalhado de cada caso de uso
Diagrama de classes de design
Fluxograma
Diagrama de máquina de estado
6.4.3 Projetar interface do usuário
O design do diálogo começa com os requisitos
O design adiciona layout de tela, aparência, navegação e experiência do usuário
Projete interfaces diferentes para dispositivos diferentes
6.4.4 Interface do sistema de projeto
Os sistemas de informação interagem com muitos outros sistemas internos e externos
As interfaces do sistema se conectam a outros sistemas de muitas maneiras diferentes
6.4.5 Banco de dados de projeto
Comece com um diagrama de classes de modelo de domínio (ou ERD)
Selecione a estrutura do banco de dados
Arquitetura de design (distribuída, etc.)
Projetar esquema de banco de dados
Tabela, coluna de atributos
Projetar restrições de integridade de referência
6.4.6 Projetar segurança e controles de sistema
O objetivo é proteger os ativos de uma organização, críticos no mundo da Internet e sem fio
Controles da interface do usuário
controle de aplicativos
Controle de banco de dados
controle de rede
6.5 Como projetar o ambiente
Projetar no local
Existem dois tipos de sistemas de software locais
Sistema de software independente
Execute a partir de um dispositivo sem rede
Sistema interno baseado na web
Implantação de hardware: LAN
arquitetura cliente-servidor
Sistema de aplicação desktop (cliente-servidor)
Sistema de aplicação baseado em navegador (servidor-navegador)
Use linguagem de marcação de hipertexto como uma página
Use o protocolo TCP/IP como protocolo de transporte
Arquitetura cliente/servidor de três camadas
Uma maneira eficaz de projetar software é separar a interface do usuário e as camadas de lógica de negócios, e separar a camada de lógica de negócios e a camada de acesso a dados. Esse método de projetar programas é chamado de arquitetura de três camadas. A ideia básica é dividir o software em três camadas
Camada de visualização: responsável por receber a entrada do usuário e processá-la em saída formatada
Camada lógica/camada de domínio Camada de domínio: Responsável pelas regras e procedimentos que implementam processos de negócios ou de processamento
Camada de dados: Responsável por gerenciar os dados armazenados, que geralmente existem em um ou mais bancos de dados
Várias camadas podem ser executadas em um único computador ou cada camada pode ser operada por um computador separado. Camadas complexas podem ser implantadas em duas ou três camadas, distribuindo a funcionalidade da camada ou implementando balanceamento de carga em computadores redundantes.
Outra ideia de design é MVC, ou seja, Model-View-Controller
Projetar implantação externa
Perguntas importantes incluem
Configuração para implantação na Internet
A proteção de dados é implementada usando Hypertext Transfer Protocol Security (HTTPS). As páginas da web atendidas pelo protocolo HTTPS são transmitidas de forma criptografada, que é mais segura que o HTTP.
Use estruturas de servidor multicamadas e balanceamento de carga e redes de distribuição de conteúdo (CDNs) para aumentar o desempenho
A estrutura do servidor multicamadas inclui servidor de aplicativos e servidor de banco de dados
As solicitações são enviadas para diferentes servidores de data center por meio de computadores de balanceamento de carga
Ao acessar algumas fotos ou vídeos estáticos, você pode usar um CDN independente para enviá-los
Opções de hospedagem para implantações na Internet
aluguel de local
Fornece um data center seguro para os clientes colocarem computadores servidores. A vantagem é que não há custos de data center físico, seguro e complexo.
Serviços gerenciados
Fornece serviços adicionais, incluindo gerenciamento de sistemas operacionais, servidores de rede, servidores de banco de dados, etc. A vantagem é que não há necessidade de contratar funcionários para gerenciar sistemas de servidores e software de sistema.
servidor virtual
Os clientes podem alugar servidores virtuais, de tamanho fixo
computação em nuvem
Os clientes só precisam adquirir a capacidade computacional de que necessitam e utilizam, e quando a capacidade computacional crescer, a nuvem fornecerá automaticamente mais capacidade. Este acordo pode economizar custos porque não há necessidade de adquirir capacidade desnecessária;
Para todas as alternativas existe um Acordo de Nível de Serviço (Service Level Agreement), que faz parte do contrato entre a empresa e a empresa de hospedagem para garantir um nível específico de disponibilidade do sistema.
Diversidade de dispositivos de clientes implantados para a Internet
computador
Tablet de médio porte
pequeno dispositivo móvel
Design para ambientes remotos e distribuídos
Implantação remota via rede privada virtual (VPN)
Uma VPN é uma rede construída em uma rede pública como a Internet. Ele fornece uma rede segura e conectável para grupos privados
chap07 Projetar interface de usuário e interface de sistema
7.2 Interface do usuário e interface do sistema
A interface do usuário contém entradas e saídas que requerem intervenção direta do usuário.
A interface do sistema requer entrada e saída manuais mínimas
7.3 Compreendendo a interface do usuário
A interface do usuário possui três componentes
Significado físico: mesas e cadeiras de escritório, luminárias, teclados, mouses, telas sensíveis ao toque
Significado percebido: cores, formas, texturas, fontes, janelas, menus, botões
Significado conceitual: cliente, participante, pedido, transporte, feedback
A perspectiva de design da interface do usuário é centrada no usuário, enfatizando a interação entre humano e computador (Interação humano-computador)
A interação humano-computador é um campo que estuda a eficiência e eficácia da interação do usuário com sistemas de computador, técnicas de entrada e saída orientadas para o ser humano e os aspectos psicológicos das interfaces do usuário.
Três princípios básicos do design centrado no usuário
Concentre-se desde o início nos usuários e em seu trabalho
Avalie o sistema para garantir sua usabilidade
Use desenvolvimento iterativo
Metáforas para interação humano-computador
Metáforas são analogias entre recursos da interface do usuário e entidades físicas familiares aos usuários.
As metáforas são amplamente utilizadas no design de interfaces de usuário nas seguintes situações:
manipulação direta
Manipule objetos físicos diretamente na tela ou objetos que os representem
Exemplo: o usuário arrasta uma pasta para a Lixeira
metáfora da área de trabalho
Organize a exibição visual em diferentes áreas, com um grande espaço de trabalho vazio no meio cercado por um conjunto de ícones de ferramentas
Exemplo: área de trabalho do Windows
metáfora do documento
Exibir dados como uma página ou tabela
Exemplo: Documento de instruções do usuário, etc.
metáfora conversacional
Usuários e computadores completam tarefas engajando-se em comunicação ou diálogo usando texto, voz ou outras ferramentas
Exemplo: janela cmd
As três primeiras enfatizam os objetos que interagem com o usuário, e a metáfora conversacional enfatiza a comunicação que ocorre entre o usuário e o computador.
7.4 Conceitos de design de interface de usuário
7.4.1 Rapidez e visibilidade
Indicativo refere-se à aparência de um controle refletindo seu desempenho
Visibilidade significa que o controle está visível
7.4.2 Consistência
7.4.3 Atalhos
7.4.4 Comentários
7.4.5 Diálogo completo
7.4.6 Tratamento de erros
7.4.7 Desfazer ação
7.4.8 Reduzir a carga sobre a memória de curto prazo
7.5 Da análise ao design da interface do usuário
7.5.1 Casos de uso e hierarquia de menus
Os menus são uma forma de organizar um grande número de casos de uso ou conversas relacionadas em uma interface de usuário
O designer deve estimar a hierarquia do menu com base no número de casos de uso
Um nível de menu geralmente contém de 5 a 10 opções
7.5.2 Diálogo e storyboards
Precisa gravar as conversas que os usuários precisam
Storyboard: exiba esta série de esboços de tela na conversa
7.6 Design da interface do usuário
7.6.1 Diretrizes para design de formulários e tabelas
Layout e formatação da interface
Consistência, rótulos e títulos, distribuição e ordem, fontes e cores
entrada de dados
Caixa de texto, caixa de listagem, caixa de combinação, botão de opção, caixa de seleção
Orientação e controle de suporte
Minimizar, maximizar, fechar, barras de rolagem, redimensionar
7.6.2 Diretrizes adicionais para interfaces de navegador
consistência
Cascading Style Sheets (CSS) - Um padrão de codificação de páginas da Web que permite aos designers de sites especificar partes de uma página que sempre têm a mesma aparência e partes que variam dependendo da tarefa ou do público.
Considerações de desempenho
Sensível às conexões de rede, quantidade de informações transferidas, tipo de informações transferidas
Imagens, vídeos e sons
Haverá problemas de compatibilidade
Usuários especiais (deficiência)
Tecnologia assistiva – software que adapta interfaces de usuário às necessidades especiais de pessoas com deficiência (como ferramentas de conversão de texto em fala e de reconhecimento de fala)
7.6.3 Diretrizes adicionais para interfaces de dispositivos móveis
Desafios no design de interfaces de usuário para dispositivos móveis
Telas pequenas, teclados e telas sensíveis ao toque, capacidade de rede limitada, diretrizes de design de aplicativos e kits de ferramentas
7.7 Determinar a interface do sistema
As interfaces do sistema são amplamente definidas como entradas e saídas que requerem pouca ou nenhuma intervenção do usuário.
Dividido nas seguintes categorias
Entrada e saída de outros sistemas
XML (Extensible Markup Language) pode ser usado para troca eletrônica de dados e comunicação entre sistemas
XML implementa incorporação de estrutura de dados personalizada em comparação com HTML
Entrada e saída altamente automatizadas
Entrada e saída de bancos de dados externos
7.8 Entrada do sistema de projeto
7.8.1 Dispositivos de entrada automatizados
O principal objetivo de qualquer entrada de dados é fornecer ou atualizar dados livres de erros no sistema. O mais importante é evitar erros tanto quanto possível.
Use dispositivos de entrada automatizados
Evite ao máximo a intervenção humana
Se as informações de entrada puderem ser obtidas em uma planilha, use a planilha sem inserir novamente os dados
Verifique e corrija os dados
7.8.2 Definir detalhes de entrada do sistema
7.9 Saída do sistema de projeto
Projetar relatórios, declarações e documentos de devolução
Tipo de relatório
Relatório detalhado: contém informações detalhadas sobre o processo de negócios
Relatório resumido: Este tipo de relatório é usado para resumir as atividades em fases.
Relatório anormal: gerado quando os resultados da transação ou operação são anormais.
Relatórios executivos: avaliar a saúde geral e as operações
A saída interna é gerada para uso interno da organização ou unidade. Os relatórios discutidos anteriormente pertencem à saída interna é gerada para uso por membros externos da organização, como informações de confirmação de pedidos, extratos de liquidação mensais, etc. Porque é um documento comercial oficial gerado para terceiros e requer uma qualidade superior
Existe um tipo de saída externa chamada documento de devolução. A saída fornecida ao usuário consiste em uma parte que pode ser destacada e usada como entrada no sistema posteriormente, como uma fatura contendo um recibo de pagamento que será devolvido junto com o documento. verificar.
extratos eletrônicos
Apresentação gráfica e multimídia
método de desenvolvimento de sistema chap08
8.2 Ciclo de vida de desenvolvimento do sistema
8.2.1 Métodos tradicionais de previsão do ciclo de vida de desenvolvimento de sistemas
O método de previsão é um método que pode planejar antecipadamente projetos de desenvolvimento organizacional e desenvolver novos sistemas de informação de acordo com o plano.
Requisitos: Presume-se que o projeto possa ser planejado com antecedência, o sistema de informação possa ser desenvolvido de acordo com o plano, os requisitos sejam bem compreendidos e o risco técnico seja baixo
modelo cachoeira
Num projeto, as seis fases do ciclo de vida progridem de uma fase para a seguinte e as fases são sequenciais.
No modelo tradicional em cascata, não há sobreposição e iteração entre os vários estágios do SDLC
O modelo no lado relativamente direito da escala é o modelo em cascata aprimorado
O modelo em cascata aprimorado ainda mantém a sequência prevista de estágios de desenvolvimento, mas esses estágios se sobrepõem, influenciam e dependem uns dos outros.
Maior flexibilidade, mas ainda pressupõe planejamento preditivo e fases sequenciais
8.2.2 Abordagem adaptativa ao ciclo de vida de desenvolvimento de sistemas
Modelos de adaptação podem ser usados para desenvolvimento quando os requisitos (requisitos) não são claros e geralmente envolvem diversas iterações.
Os projetos precisam de ser mais flexíveis e adaptar-se às necessidades em constante mudança durante o processo de desenvolvimento; a procura é incerta e os riscos técnicos são elevados;
modelo espiral
Relativamente longe da extremidade direita da escala
Use uma espiral para descrever o SDLC, começando do centro e expandindo-se continuamente até que o projeto seja concluído.
Mais de uma vez por etapa
modelo iterativo
Semelhante ao método de desenvolvimento do Capítulo 1, as linhas da tabela são atividades de desenvolvimento e as colunas são iterações.
Cada iteração contém vários estágios, e cada estágio não será concluído de uma só vez, mas será continuamente melhorado nas iterações subsequentes.
Conceitos adicionais sobre abordagens adaptativas
desenvolvimento incremental
O conceito básico é que os sistemas são construídos em pequenos incrementos, crescendo organicamente
Durante o projeto, o sistema é implementado em etapas e parcialmente implantado
A vantagem é que os usuários podem obter rapidamente parte do sistema para que o negócio possa ser lançado o mais rápido possível.
esqueleto ambulante
Uma abordagem inicial para construir uma estrutura de sistema completa, mas fornecendo apenas funções básicas
Primeiro, forneça um "esqueleto" do processo completo de implementação do novo sistema, do início ao fim, e depois use as iterações subsequentes para preencher o esqueleto.
Em projetos, muitas vezes não é uma escolha extrema
8.3 Fase de suporte
A abordagem preditiva SDLC inclui tal fase de suporte
A abordagem adaptativa trata a fase de suporte como um projeto completo e independente
Três atividades principais ocorrem durante a fase de suporte
Sistema de manutenção
Fortalecer o sistema
Apoiar usuários
8.4 Métodos, modelos, ferramentas e técnicas
métodos de desenvolvimento de sistema
O escopo do método é o maior
Uma metodologia inclui um conjunto de técnicas para concluir atividades e tarefas, incluindo a modelagem de todos os aspectos de um projeto.
Modelo
Um modelo é uma representação abstrata de algum aspecto específico do mundo real que torna possível compreender um conceito complexo concentrando-se apenas nas partes relevantes.
Cada modelo enfatiza informações diferentes
Já entramos em contato com alguns destes modelos: diagrama ER, diagrama de casos de uso, diagrama de classes, diagrama de sequência
ferramenta
suporte de software
tecnologia
adquirido através do aprendizado
8.5 Dois métodos de construção e modelagem de software
8.5.1 Abordagem estruturada
O método estruturado concentra-se no processo e é centrado no fluxo de dados. Ele pressupõe que o sistema é uma coleção de processos que interagem com o fluxo de dados.
O método estruturado é o mesmo método tradicional do método de predição SDLC.
Análise estruturada
Modelagem usando Diagrama de Fluxo de Dados
Diagramas ER também serão usados
projeto estruturado
Projetar programas usando diagramas de estrutura
Requer baixo acoplamento e alta coesão
Baixo acoplamento significa que diferentes módulos são tão independentes quanto possível de outros módulos, de modo que a modificação de um módulo não afetará a operação de outros módulos.
Alta coesão significa que cada módulo implementa uma tarefa clara
programação estruturada
Inclui um começo, um fim e três estruturas: sequência, seleção, ciclo
Programação de cima para baixo/design modular
8.5.2 Abordagem orientada a objetos
A abordagem orientada a objetos vê um sistema como uma coleção de objetos que trabalham juntos para realizar uma determinada interação.
Objetos são coisas no sistema que respondem a mensagens
análise orientada a objetos
O processo de identificação e definição de casos de uso e conjuntos de objetos (classes) em um novo sistema
design orientado a objetos
Defina todos os tipos de objetos necessários para se comunicar com pessoas e dispositivos e mostre como eles interagem para concluir tarefas
Use modelos como diagramas de classes e diagramas de casos de uso
Programação Orientada a Objetos
Escreva instruções para definir a classe real e a função de cada objeto da classe
Use modelos como diagramas de sequência e diagramas de classes de projeto
8.6 Desenvolvimento ágil
Atividades de desenvolvimento conduzidas em um ambiente desconhecido e em rápida mudança
8.6.1 Teoria e valor do desenvolvimento ágil
teoria central
Concentre-se em responder às mudanças em vez de seguir um plano
Valorize indivíduos e interações em vez de processos e ferramentas
Valorize o software funcional em vez da documentação abrangente
Concentre-se na colaboração do cliente em vez de negociações contratuais
Descreva o conceito de projetos ágeis: caos
Isso é caos e ordem: as duas primeiras teorias centrais – o domínio dos valores individuais sobre os valores do grupo – são a causa do caos, e esse caos pode ser tratado com flexibilidade crescente. O caos é inevitável durante o processo de desenvolvimento imprevisível. Os desenvolvedores precisam aceitar o caos, mas às vezes é necessário usar outros métodos e técnicas que sejam benéficos para adicionar ordem e estrutura ao projeto.
Simplificando, significa permitir que ocorra algum caos e, ao mesmo tempo, garantir a ordem geral.
cap09 Planejamento e gerenciamento de projetos
Estas são as duas primeiras das seis seções principais: Identificar o problema e obter aprovação, Planejar e monitorar o projeto
9.2 Princípios de Gerenciamento de Projetos
9.2.1 Requisitos para gerenciamento de projetos
Segundo as estatísticas, menos de um terço dos projectos bem sucedidos
Razões pelas quais alguns projetos falham
Principal razão: Falta de envolvimento da alta administração e de habilidades de gestão
Falta de participação do grupo de usuários
9.2.2 O papel do gerente de projeto
O gerenciamento de projetos é o processo de organizar e direcionar outras pessoas para alcançar os resultados planejados de acordo com um cronograma e orçamento previamente determinados. Também pode ser definido como o processo de planejar um projeto e depois monitorá-lo e controlá-lo.
Responsabilidades Internas do Gerente de Projeto
Desenvolver cronograma do projeto
Recrutar e treinar membros da equipe
Coordenar o trabalho entre os membros da equipe
Avalie os riscos do projeto
Monitore e controle os marcos do projeto
Gerencie pessoas e recursos
Responsabilidades externas do gerente de projeto
Relatar o status e o progresso do projeto
Trabalhe diretamente com clientes e outras partes interessadas
Determinar as necessidades de recursos e obter recursos
Coordenar relações públicas
Os gerentes de projeto trabalham com diversos grupos de pessoas
Cliente: A pessoa que financia o sistema
Comitê de Supervisão: composto pelo cliente e outros gerentes seniores para supervisionar o projeto
Usuário: uma pessoa que usa diretamente o sistema para concluir tarefas
Os gerentes de projeto têm funções duplas internas e externas
9.2.3 Gerenciamento do projeto e cerimônia (cerimônia)
O grau de formalidade de um projeto, ou ritual, também tem impacto no gerenciamento do projeto
Projetos menores geralmente realizam rituais de baixo custo
Projetos maiores e mais complexos costumam realizar cerimônias de alta qualidade
Os rituais do projeto diferem ao usar métodos preditivos tradicionais versus métodos adaptativos
Os projetos adaptativos podem muitas vezes ser mais formais ou informais nos seus métodos de gestão: o UP (Processo Unificado) é bastante formal e tem rituais rígidos, enquanto os métodos iterativos são mais informais
9.2.4 Sistema de conhecimento de gerenciamento de projetos
PMBOK, consiste em nove módulos
Gerenciamento de escala de projeto
Gerenciamento de tempo do projeto
gerenciamento de custos do projeto
Gestão da qualidade do projeto
Gestão de Recursos Humanos do Projeto
Gerenciamento de comunicação do projeto
gerenciamento de risco do projeto
Gerenciamento de aquisições de projetos
Gerenciamento integrado de projetos
9.2.5 Gerenciamento ágil de projetos
Gerenciamento ágil de projetos
O escopo não é bem compreendido, mas precisa ser controlado
Use várias diretrizes para determinar as prioridades de negócios
Gerenciamento de tempo ágil
O horário deve ser flexível para acomodar mudanças
Gestão ágil de custos
Os custos são mais difíceis de estimar, portanto o controle de custos não é tão importante quanto numa abordagem preditiva
Gerenciamento ágil de riscos
Aspectos de alto risco do projeto são concluídos primeiro
Gestão ágil da qualidade
Realizar avaliação de qualidade após cada iteração
9.3 Processo Principal 1: Identificar o Problema e Obter Aprovação
9.3.1 Identifique o problema
Três objetivos principais para o desenvolvimento de novos sistemas
Responder a novas oportunidades de desenvolvimento
ocupar participação de mercado
Resolver problemas de negócios existentes
Responder a comandos externos
Legal, fiscal etc.
Uma maneira eficaz de definir o problema é criar um Documento de Visão do Sistema (SVD)
Inclui três partes
Descrição do Problema
Quais são os problemas e soluções?
Capacidades do sistema
Quais recursos o novo sistema terá?
benefícios comerciais
Benefícios para a organização (tangíveis ou intangíveis)
9.3.2 Quantificar os fatores de aprovação do projeto
Precisa ser claro
Tempo estimado de conclusão
Custos estimados de desenvolvimento
Custos de funcionamento estimados
Pré-ganhos
análise de custo-benefício
alguns conceitos
VPL (valor presente líquido) valor presente líquido
O valor presente dos benefícios e custos de um determinado investimento
Calculado subtraindo os custos usando "ganhos atuais" (usando um fator de desconto)
ponto de recuperação de custos
Durante este período, os ganhos do dólar compensaram os custos do dólar
Benefícios tangíveis
A parte do benefício que pode ser medida em termos de dinheiro
benefícios intangíveis
Benefícios para a organização, mas não podem ser medidos quantitativamente ou estimados com precisão
Melhorias nos níveis de serviço (de maneiras que não podem ser medidas em dólares)
Maior satisfação do cliente (não mensurável em dólares)
Sobrevivência - preciso competir assim
Necessidade de desenvolver conhecimentos internos (por exemplo, projetos-piloto para novas tecnologias)
método de análise de custo/benefício
Use o valor presente como valor estimado
Calcular a vida útil do sistema
Calcule o período de retorno e a receita final acumulando o valor presente líquido a cada ano
Exemplo
O período de retorno usa os pontos de viragem positivos e negativos do valor presente líquido acumulado como parte inteira, e a parte decimal é calculada usando (último valor negativo/diferença total)
9.3.3 Avaliação de risco e análise de viabilidade
Determine o risco e a viabilidade da organização
Avalie riscos técnicos e viabilidade
Avalie o risco e a viabilidade dos recursos
Determine os riscos e a viabilidade do cronograma
9.3.4 Trabalhar com clientes na aprovação
Revisão e aprovação do Comitê Executivo
Os Conselhos de Administração devem revisar e aprovar projetos muito grandes
As partes interessadas envolvidas precisam entender o que se espera delas
Os departamentos de SI precisam saber o que fazer em termos de pessoal e suporte
Toda a organização deve estar ciente deste projeto e da sua importância
9.4 Processo Central 2: Planejar e Monitorar Projetos
9.4.1 Estabelecer o ambiente do projeto
Diferente do design do ambiente mencionado anteriormente, o ambiente do projeto aqui se refere ao ambiente de trabalho e comunicação dentro e fora da equipe, e não à tecnologia exigida pelo sistema, etc.
Registros e Comunicações - Internas/Externas
Ambiente de Trabalho – Suporte/Equipamentos/Ferramentas
PC ou estação de trabalho
Software e ferramentas de desenvolvimento pessoal
Servidor com biblioteca de recursos, ferramentas de comunicação
Escritórios, salas de conferências, impressoras e outros equipamentos
Apoiar funcionários (fora da equipe)
Processos e Procedimentos
Relatórios e Documentação
programação
teste
Entregáveis
Controle de código e versão
9.4.2 Organizar o progresso do trabalho
Use o cronograma de iteração do projeto para atribuir casos de uso às iterações
Agende um cronograma detalhado de tarefas e trabalhos que precisam ser concluídos em cada iteração – use um cronograma de trabalho detalhado
Três etapas para criar um cronograma de trabalho iterativo detalhado
Criar estrutura analítica do trabalho WBS
Estimando esforço e identificando dependências
Crie um cronograma usando um gráfico Gatt
A estrutura analítica do trabalho contém
Base de decomposição
tempo requerido
Ordem de execução
Avalie o tempo com base em informações relevantes da EAP e descubra dependências, possivelmente usando o caminho crítico
Um gráfico de Gantt é um gráfico de barras com atividades em barras e exibido em uma linha do tempo horizontal
Exceto a primeira tarefa, toda tarefa possui uma tarefa predecessora.
A parte clara é o caminho crítico, que afeta todo o progresso e precisa ser monitorado de perto.
9.4.3 Alocação de pessoal e recursos
cinco tarefas
Criar um plano de recursos no projeto
Identificar e solicitar funcionários técnicos específicos
Identifique e solicite funcionários de usuários específicos
Organize equipes em grupos de trabalho
Estabeleça treinamento inicial e exercícios de formação de equipe
9.4.4 Processo de trabalho de avaliação
exposição retrospectiva
9.4.5 Processo de monitoramento e correção
Atribuir trabalho a indivíduos ou equipes
status da coleção
A tarefa foi concluída e o objetivo alcançado?
Analisar anomalias
As exceções importam?
tome a atitude certa
cap10 Design orientado a objetos: princípios de design
10.2 Design orientado a objetos: a ponte entre análise e implementação
10.3 Projeto de arquitetura orientada a objetos (design de alto nível)
Os sistemas de software são geralmente divididos em dois tipos
Sistema monousuário: executado no desktop do usuário ou em um servidor sem compartilhamento de recursos
Sistemas de nível empresarial: os componentes podem ser compartilhados entre várias pessoas ou organizações
Sistema Servidor/Cliente
Sistema de Internet (navegador/servidor)
Três diferenças básicas que afetam o design da arquitetura do sistema
estado
Cliente/servidor é um sistema baseado em estado e as conexões cliente/servidor são de longa duração
Os sistemas da Internet são sistemas sem estado e as conexões não são de longo prazo
Implantação do cliente
Exibição direta de telas e tabelas
Telas e tabelas são exibidas através do navegador
Implantação de servidor
Aplicativo ou cliente se conecta diretamente ao servidor
O cliente se conecta indiretamente ao servidor de aplicativos por meio do navegador
Diagrama de Componentes e Projeto de Arquitetura
Um tipo de diagrama de projeto que mostra a arquitetura geral do sistema e os componentes lógicos dentro dele, ilustrando como o sistema será implementado
O diagrama de componentes identifica os componentes do sistema para lógica, reutilização e portabilidade
Os elementos básicos de um diagrama de componentes são elementos componentes com APIs.
APIs são métodos públicos que podem ser acessados pelo mundo exterior
Existem dois tipos de APIs em diagramas de componentes
Soquete de entrada (soquete)
Porta de saída (Porta)
Exemplo
Caso: Projeto de arquitetura de duas camadas da Internet (na verdade, também pode ser de três camadas)
Camada de interface do usuário (camada de visualização)
Camada de domínio (camada lógica)
Camada de acesso ao banco de dados (camada de dados)
Representar usando diagramas de componentes
10.4 Princípios básicos do projeto detalhado orientado a objetos
Etapas de design detalhado orientado a objetos
Desenvolva diagramas de classes de projeto preliminares
Use cartões CRC para determinar responsabilidades de classe e cooperação para casos de uso
Desenvolva diagramas de sequência detalhados para cada caso de uso: desenvolva primeiro diagramas de sequência preliminares e depois diagramas de sequência multicamadas
Adicione características do método e informações de navegação
Divida a solução em pacotes (diagrama de pacotes)
10.5 Classe de projeto e diagrama de classes de projeto
10.5.1 Símbolos de projeto
Um protótipo é uma forma de classificar elementos com base em suas características, representadas por <<>>
Existem quatro tipos de protótipos de design
Classe de entidade
O identificador de design da classe de domínio do problema, geralmente persistente, representado por <<entidade>>
Classes persistentes referem-se a classes que ainda possuem dados após o desligamento do sistema. Ao implementar métodos, seus dados são gravados no banco de dados ou arquivo.
Exemplo
Alunos e professores no sistema de gestão educacional
Classe de controle
É uma classe que desempenha um papel de coordenação entre classes de visualização e classes de entidade, semelhante a roteadores ou switches, representada por <<controlador>>
Ver aula
As classes de visualização, ou classes de limite, estão no limite de automação do sistema, semelhantes a caixas de entrada ou páginas da web, voltadas para os usuários, e são representadas por <<limite>>
Classe de acesso ao banco de dados
É uma classe que obtém dados do banco de dados e os retorna, representada por <<dataAccess>>
Cada classe de protótipo possui um símbolo diferente
10.5.2 Representação da classe de projeto
Definir o formato dos atributos em uma classe de design
visibilidade
Indica (ou -) se a propriedade pode ser acessada diretamente por outro objeto. Geralmente private(-) em vez de public()
Nome da propriedade
caixa de camelo minúscula
expressão de tipo
classe, string, inteiro, duplo, data
valor inicial
propriedade
Entre chaves, como {key}
Defina o formato do método (características do método)
visibilidade do método
nome do método
Tipo de valor de retorno do método
lista de parâmetros
Exemplo
Há dois pontos entre o nome e o tipo da propriedade, assim como entre a lista de parâmetros e o tipo de valor de retorno do método há um sinal de igual antes do valor inicial;
Use nomes de classes em itálico para indicar classes abstratas
Classes que permitem apenas herança, mas não instanciação, geralmente representam conceitos abstratos de nível superior
10.5.3 Desenvolver diagramas de classes de projeto preliminar
Refinamento de atributos
Os designers determinam os tipos de atributos com base na experiência. Na maioria dos casos, os atributos são invisíveis (privados).
Visibilidade de navegação
A visibilidade da navegação refere-se a se uma classe é visível ou invisível para outra classe, indicando a capacidade de um objeto ver e interagir com outro objeto.
Use uma seta para indicar que a direção apontada é o lado visível
Neste exemplo, cliente refere-se à classe de venda, portanto a venda fica visível para o cliente, mas o cliente não fica visível para a venda.
Tipo de visibilidade de navegação
Representa um relacionamento um-para-muitos entre superiores e subordinados, geralmente apontando de superiores para subordinados.
Associação forçada, onde um objeto em uma classe não pode existir sem um objeto em outra classe, normalmente navegando de uma classe mais independente para uma classe dependente
Por exemplo, no cliente e na venda acima, a venda não tem sentido quando não há clientes.
Quando um objeto requer informações de outro objeto, uma seta de navegação pode ser necessária
A visibilidade da navegação pode ser bidirecional
Etapas para desenvolver diagramas de casos de uso preliminares
Caso de uso após caso de uso, adicionado ao diagrama
Selecione as classes de domínio envolvidas no caso de uso (veja a ideia de pré-requisitos e pós-condições)
Pré-condições e pós-condições devem estar na descrição do caso de uso no Capítulo 5
Adicione uma classe de controlador para cuidar do caso de uso
Use diretrizes para determinar as necessidades iniciais de visibilidade da navegação e adicione-as ao diagrama
Descreva as propriedades de cada classe detalhadamente com visibilidade e tipo
Observe que as associações e a multiplicidade são frequentemente removidas dos diagramas de classes de projeto, assim como a navegação é enfatizada no texto, mas muitas vezes são mantidas
Do diagrama de classes de domínio ao diagrama de classes de projeto preliminar
10.6 Usando cartões CRC para projeto detalhado
Cartão CRC significa Classe, Responsabilidade, Colaboração
O design orientado a objetos trata da atribuição de responsabilidades às classes e de como elas funcionam juntas para concluir um caso de uso.
O cartão CRC é dividido em três áreas: nome da classe, nome da responsabilidade e classe de cooperação
Passos para usar o cartão CRC
Comece com um conjunto de cartões CRC não utilizados e vá analisando um caso de uso após o outro
Selecione um caso de uso e selecione uma placa como seu controlador
Determine a classe de domínio principal responsável por este caso de uso. Os objetos desta classe receberão mensagens do controlador, determinem as responsabilidades e escrevam-nas no lado esquerdo do cartão.
Identifique outras classes que cooperam com a classe de objeto principal para completar o caso de uso e escreva-as no lado direito do cartão CRC
Depois de determinar as categorias de cooperação, execute as operações acima para cada categoria de cooperação (determinar responsabilidades/encontrar categorias de cooperação)
Classes de interface do usuário e classes de acesso ao banco de dados podem ser adicionadas apropriadamente
Use os resultados do cartão CRC para atualizar o diagrama de classes de projeto preliminar
Atualize o método: a responsabilidade no cartão CRC passa a ser um método (mas não há visibilidade e expressão de tipo de retorno, ou seja, nenhuma característica do método é adicionada)
Atualizar a visibilidade da navegação
Exemplo
Diagrama de classes de projeto preliminar
Diagrama de classes de design atualizado
10.7 Alguns princípios de projeto detalhado
acoplamento baixo
Alta coesão
Proteção variável
indireto
Responsabilidades do Objeto
cap11 Design orientado a objetos: implementação de design
11.2 Projeto detalhado de sistemas multicamadas
Padrões de design
Padrões de design – técnicas e modelos de design padrão amplamente reconhecidos como boas práticas
Para problemas comuns de design/codificação, os padrões de design sugerem a melhor maneira de lidar com o problema.
elementos de padrões de design
Nome do esquema
Problemas que exigem soluções
modelo de resolução de problemas
Caso padrão
Benefícios e consequências dos padrões
O primeiro exemplo de padrão de projeto de programação é o padrão Controller.
Os controladores de caso de uso são criados artificialmente para passar mensagens da camada de visualização para a camada de domínio para reduzir o acoplamento.
Vantagens e consequências
Reduz o acoplamento entre a camada de domínio e a camada de visualização
fornece uma camada de indireção
Controladores e classes de domínio estão fortemente acoplados
Se você não tomar cuidado, o controlador conterá muita lógica irrelevante, especialmente lógica de negócios.
11.3 Implementação de caso de uso e diagrama de sequência SSD
Implementação de casos de uso - o processo de projetar casos de uso detalhadamente usando diagramas de interação
Existem dois tipos de diagramas de interação
Fluxograma
Os diagramas de sequência são mostrados estendendo o diagrama de sequência do sistema
visualizar objeto de camada
Objetos da camada de domínio (geralmente feitos primeiro)
objeto da camada de acesso a dados
Diagrama de colaboração
11.3.1 Compreendendo diagramas de sequência
A diferença entre o diagrama de sequência do sistema e o diagrama de sequência
O diagrama de sequência do sistema possui apenas um objeto, que representa o sistema: sistema, enquanto o diagrama de sequência estende o objeto para o interior do sistema.
O diagrama de sequência do sistema possui apenas duas linhas de vida, representando os atores e o sistema e cada objeto no diagrama de sequência possui uma linha de vida, embora o comprimento possa ser diferente (o tempo começa quando o objeto é criado).
No mesmo caso de uso, a parte do limite de automação do diagrama de sequência do sistema e do diagrama de sequência é a mesma (o todo permanece inalterado), ou seja, a entrada para o sistema e a saída do sistema para o exterior são os mesmo.
Os diagramas de sequência têm uma seção especial de linha de vida chamada linha de vida da atividade.
A linha de vida da atividade representa o tempo em que um objeto está no estado de execução ativo. O estado ativo dura até que todos os dados sejam salvos ou outros métodos sejam chamados.
Neste diagrama de sequência de criação de um caso de uso do usuário: Customform e CustomHandler foram criados, e o objeto Custom é criado após o método createCustom, portanto, o horário de início da linha de vida é diferente e a barra retangular é a linha de vida ativa;
11.3.2 Processo de design de implementação de caso de uso
etapas de projeto
Desenvolva um diagrama de classes de projeto preliminar mostrando a visibilidade da navegação
Use cartões CRC para atribuir funções a classes em casos de uso
Desenvolva diagramas de sequência detalhados para cada caso de uso
Diagrama de sequência preliminar
Diagrama de sequência multinível
Use cartões CRC e diagramas de sequência detalhados para atualizar diagramas de classes de projeto e adicionar recursos de método
Diagramas de classes de design de pacote
11.3.3 Caso: Diagrama de classes de projeto preliminar para criação de uma conta de usuário
Desenvolva um diagrama de sequência preliminar com base no diagrama de classes de projeto preliminar desenvolvido anteriormente
Expanda o diagrama de seqüência do sistema e marque os objetos de classe que precisam ser usados no sistema original: e ainda há dois pontos na frente dele.
Determine mensagens internas entre objetos, adicione mensagens e ativações para completar a colaboração
O formato da mensagem é consistente com o diagrama de sequência do sistema: *[codição] return_value:=function_name(parameter_list) Você também pode usar uma seta reversa tracejada como valor de retorno
sub tópico
11.3.5 Diretrizes e suposições para o desenvolvimento de diagramas de sequência preliminares
guia
Aceite cada mensagem e identifique outras mensagens internas resultantes desta mensagem de entrada
Ao processar cada mensagem, especifique o conjunto de classes afetadas
Enriqueça a estrutura da mensagem, adicione condições verdadeiras e falsas, loops, valores de retorno, transferência de parâmetros, etc.
hipótese
Hipótese de perfeição técnica
hipótese de perfeição de memória
nenhuma suposição de anomalia
11.3.6 Desenvolvimento de diagramas de sequência multicamadas
O acima é apenas um diagrama de sequência preliminar para a camada de domínio (camada lógica). Para descrever os casos de uso com mais detalhes, você precisa desenvolver diagramas de sequência para a camada de acesso a dados e a camada de visualização.
11.4 Use o diagrama de comunicação do diagrama de colaboração
11.5 Atualização e diagrama de classes de design de pacote
Atualizar diagrama de classes de design
Com base nas informações do diagrama de sequência, adicione recursos de método para atualizar o DCD
Três tipos de métodos
Método construtor: crie uma nova instância de objeto
Métodos de leitura e gravação de dados: obter ou atualizar valores de atributos
Use métodos específicos de caso: incluídos no diagrama de classes de design
Mapa do pacote
Um diagrama de pacotes é um diagrama de alto nível que associa grupos relacionados de classes
Use ícones semelhantes a pastas para representar pacotes, e as classes são colocadas em pacotes correspondentes de acordo com as camadas às quais pertencem.
Use setas pontilhadas para indicar dependências, incluindo dependências entre classes e dependências entre pacotes.
Exemplo
Diagrama de pacote parcial com apenas um caso de uso
Diagrama de pacote do subsistema
11.6 Outros padrões de design comuns
adaptador
Quando dois sistemas precisam ser conectados, mas as interfaces entre eles não coincidem, é necessário um adaptador.
Conecte interfaces incompatíveis reescrevendo dados
Por exemplo: ao enfrentar fornecedores diferentes (impostos, despesas de envio), você só precisa reescrever o adaptador
fábrica
As classes de fábrica são usadas para criar muitos tipos diferentes de instâncias de classe de utilitário
Geralmente, uma classe de ferramenta precisa apenas de uma instância, e a fábrica deve garantir que haja apenas uma instância.
Solteiro
Um singleton possui uma variável estática apontando para uma instância dele mesmo. Verifique esta variável através de algum método. Se estiver vazio, você pode criar uma instância e atribuí-la à variável; se não estiver vazio, você pode retornar diretamente a instância da variável;
Conexão de classe{ conexão estática privada=null; público sincronizado estático getConnection(){ if conn==nulo{ conn=nova conexão(); } conexão de retorno; } }
Fábrica e singleton
A lógica básica das fábricas e dos singletons é a mesma: ambas servem para garantir que haja apenas uma instância do objeto e economizar sobrecarga de memória.
Mas a fábrica precisa ser responsável por múltiplas classes; o singleton verifica apenas as variáveis de instância estáticas dentro da classe;