O ciclo de vida do software é dividido em estudo de viabilidade, análise de requisitos, projeto geral, projeto detalhado, implementação, teste de montagem (integração),

Confirme as 10 etapas de teste, uso, manutenção e descomissionamento, conforme mostrado na figura abaixo:

Descrevemos o processo de desenvolvimento de software de forma simples e compreensível:

Estudo de viabilidade: Simplificando, o estudo de viabilidade é se o software que queremos projetar pode ser concluído usando a tecnologia atual, se o tempo e o capital consumidos para a conclusão estão dentro de uma faixa razoável, se a função do software pode resolver os problemas atuais existentes, e se o software atual pode ser concluído.Se o desenvolvimento pode trazer benefícios positivos para a empresa.

Análise de requisitos: analise a função e eficiência do software, que desempenha um papel decisivo no desenvolvimento de todo o software e, finalmente, gere a especificação de requisitos de software de acordo com a função e eficiência do software

Outline design: projetar a parte pública do software, incluindo interfaces, protocolos e restrições (overall constraints), principalmente para um design geral do programa, sem envolver a implementação detalhada de cada função

Projeto detalhado: projeto detalhado de cada negócio e processo do software, incluindo a operação e design específicos de cada negócio

Realização: Realizar cada negócio

Teste de montagem (integração): Implante o software e teste todas as funções

Teste de confirmação: deixe o usuário confirmar se todas as funções atendem às expectativas e aceite todo o software

Manutenção: Através de várias atividades de manutenção necessárias, o sistema pode atender às necessidades dos usuários por um longo tempo

Desativação: encerramento do suporte para um produto de software, software descontinuado

2. Classificação da arquitetura do projeto

A arquitetura de projetos gerais é dividida principalmente em dois tipos: arquitetura C/S e arquitetura B/S

Arquitetura C/S é rack cliente/servidor

Arquitetura B/S é rack de navegador/servidor

arquitetura C/S

O nome completo da arquitetura C/S é arquitetura cliente/servidor (cliente/servidor), que é uma arquitetura de duas camadas comumente usada. O cliente precisa instalar o cliente

Software cliente, o programa do servidor é executado no servidor e fornece serviços de soquete ou banco de dados.

vantagem:

• A maior parte dos negócios pode ser feita no lado do cliente, fazendo pleno uso dos recursos do computador local

• Resposta rápida

• Forte capacidade de personalização

• Voltado para um grupo de usuários relativamente fixo, tem forte capacidade de controlar a segurança da informação

deficiência:

• Precisa instalar o cliente para usar

• Alto custo de manutenção, qualquer problema com o cliente em qualquer computador precisa ser mantido e o processo de atualização é complicado

estrutura B/S

O nome completo da arquitetura B/S é a estrutura navegador/servidor (Browser/Server), que se divide em navegadores Web, programas servidores e servidores de banco de dados.

Pode ser entendido como uma melhoria na arquitetura C/S. Como toda a lógica de negócios é processada pelo programa do servidor, o cliente pode concluir todas as operações apenas usando o navegador, o que reduz muito o custo de manutenção do cliente.

Os programas que atualmente projetamos usando java pertencem à arquitetura BS

vantagem:

• Zero manutenção no lado do cliente, só precisa instalar um navegador

• Todos os negócios estão concentrados no lado do servidor, a expansão dos negócios é muito conveniente

• Baixo custo de manutenção, só precisa manter o servidor

deficiência:

• Enviar solicitações e receber respostas pela rede, que é bastante afetada pela rede

• A segurança do servidor e os recursos de processamento de negócios exigem muito esforço e custo

• Suporte insatisfatório para diferentes navegadores

3. Explicação detalhada dos requisitos de software

Classificação das necessidades

a. Requisitos de negócios: refere-se aos requisitos-alvo da empresa ou cliente para o sistema, geralmente de dentro da empresa, ou seja, o negócio principal do software

b. Requisitos do usuário: descrevem os objetivos específicos dos usuários ou as tarefas que os usuários exigem que o sistema seja capaz de concluir. (Necessidades próprias do usuário além das necessidades de negócios)

c. Requisitos do sistema: Descreva os requisitos do software da perspectiva do sistema, incluindo requisitos funcionais (funções que o sistema deve implementar), requisitos não funcionais

(como qualidade de software, capacidade de manutenção, eficiência, etc.) e restrições de design (algumas restrições de entrega, como bancos de dados com direitos de propriedade intelectual independentes devem ser usados e devem ser executados em um determinado sistema operacional) etc.

aquisição de demanda

Existem principalmente as seguintes maneiras de obter requisitos:

a. Entrevistas com usuários: a forma mais básica.

b. Pesquisa por questionário: Como é demorado entrevistar os usuários um a um e o tempo do usuário pode não permitir uma participação oportuna na entrevista, é possível preparar um questionário com antecedência para o usuário preencher e, em seguida, conduzir um entrevista em pequena escala com base nos resultados , o que pode ser visto como uma otimização .

c. Amostragem: Amostragem de uma população específica, estudo das amostras selecionadas e obtenção de informações úteis. Para o desenvolvimento de sistemas de informação, os documentos são agora a população de amostragem.

d. Storyboard: explique como o sistema deve funcionar por meio de uma imagem e slides do sistema.

análise de demanda

Depois de obter os requisitos, realizar o trabalho de análise de requisitos específicos e, finalmente, formar a especificação de requisitos de software como a entrega para a próxima etapa

conquista

a. Desenhe o diagrama de contexto do sistema: um modelo simples usado para definir os limites e interfaces entre o sistema e as entidades externas do sistema, para os requisitos

Determinar o escopo;

b. Crie um protótipo de interface do usuário: você pode desenvolver um protótipo com ferramentas de desenvolvimento rápido ou fazer um protótipo de demonstração com ferramentas de apresentação, como apresentações de slides e Flash e até mesmo desenhar algumas interfaces importantes com caneta e papel. Diagrama esquemático da interface, para ajudar os usuários entendem os problemas a serem resolvidos e entendem o sistema;

c) Análise de viabilidade de requisitos: realizar estudos de viabilidade dos requisitos obtidos em termos de custo, desempenho e realização técnica, se há conflitos com outros requisitos, se há dependências externas, etc.;

d) Determinação da prioridade dos requisitos: É uma base importante para a formulação de planos de iteração, que pode ser explicada . A satisfação indica a satisfação do usuário quando o requisito é realizado, e a insatisfação indica a insatisfação ;

e. Construir um modelo para os requisitos: a principal forma de expressão é um diagrama mais uma pequena descrição de texto, e a descrição gráfica torna os requisitos mais claros e fáceis de entender . O modelo de análise de requisitos descreve principalmente os dados, funções, interface do usuário e comportamento externo do sistema, e não envolve os detalhes específicos de implementação do software.Ao para posterior projeto de software;

f. Crie um dicionário de dados: defina todos os itens e estruturas de dados usados pelo sistema para garantir que os desenvolvedores usem uma definição

4. Explicação Detalhada da Análise Orientada a Objetos (OOA)

Entendimento do conceito:

1 Análise Orientada a Objetos (OOA)

Ocorre no estágio de análise de requisitos para resolver o problema "o que fazer", a principal tarefa é determinar os atributos e métodos do objeto, objetos e objetos

A relação entre cada operação, o processo específico de cada operação, mas não considera os fatores relacionados à implementação específica do sistema;

2.2 Projeto Orientado a Objetos (OOD)

Ocorre na fase de projeto do sistema e resolve o problema de "como fazer". Suas ideias básicas incluem abstração, encapsulamento e escalabilidade, e sua

A escalabilidade média é alcançada principalmente por meio de herança e polimorfismo. A principal tarefa é padronizar a engenharia dos objetos de implementação, gerenciar a interdependência de várias partes dentro do programa e fornecer orientação e base para a programação orientada a objetos;

2.3 A Programação Orientada a Objetos (POO) ocorre durante o desenvolvimento do sistema, usando

Linguagem de Modelagem Unificada UML

UML (Unified Modeling Language) é uma linguagem de modelagem fácil de expressar, poderosa e universalmente aplicável.

A função não se limita a suportar OOA e OOD, mas também suporta todo o processo de desenvolvimento de software a partir da análise de requisitos.

Componentes importantes da UML:

◦ Coisas : Coisas também são chamadas de elementos de modelagem, incluindo coisas estruturais, coisas comportamentais, coisas hierárquicas e coisas de anotação, que são os blocos de construção OO mais básicos em modelos UML;

◦ Relacionamento : UML usa relações para combinar várias coisas. As principais relações são: dependência, associação

(associação), generalização, realização;

◦ Diagramas: incluem principalmente diagramas de classes, diagramas de objetos, diagramas de componentes, diagramas de estrutura composta, diagramas de casos de uso, diagramas de sequência, diagramas de comunicação, diagramas de tempo, diagramas de estado, diagramas _

Do ponto de vista do usuário, ele não quer entender a estrutura interna e o design do sistema, o que importa é o serviço que o sistema pode fornecer.

Ele registra os requisitos obtidos dos usuários, os sintetiza e refina e estabelece modelos de casos de uso. No método OOA, a construção de um modelo de caso de uso geralmente precisa passar pelos seguintes estágios, respectivamente, identificando participantes, mesclando requisitos para obter casos de uso, refinando descrições de casos de uso e ajustando modelos de casos de uso, dos quais os três primeiros estágios são necessários .

Elementos de um diagrama de caso de uso

Um caso de uso é uma forma de descrever os requisitos do sistema. Em um diagrama de caso de uso, ele inclui principalmente três elementos: atores, casos de uso e associações de comunicação:

Como mostrado na figura:

Ator: Um participante é qualquer coisa que existe fora do sistema e interage com o sistema, pode ser um usuário que usa o sistema

usuários, ou outros sistemas e dispositivos externos, etc.;

Casos de Uso: Refere-se a ações executadas no sistema que resultam em resultados visíveis aos atores. Ou seja, os casos de uso representam os serviços fornecidos pelo sistema, que definem como o sistema é usado pelos participantes e descrevem um diálogo entre os participantes para usar os serviços e usos fornecidos pelo sistema;

Associação de comunicação: representa o relacionamento entre atores e casos de uso, ou o relacionamento entre casos de uso e casos de uso. A parte apontada pela seta é o destinatário passivo do diálogo , e a parte apontada pela cauda da seta é o iniciador ativo do diálogo. Se você não quiser enfatizar o relacionamento ativo e passivo no diálogo, você pode use a linha de relação sólida sem a seta.

identificar os participantes

Os participantes são todas as coisas que interagem com o sistema, não só podem ser realizadas por pessoas, mas também por outros sistemas e dispositivos de hardware, preste atenção

Além do mais, os participantes devem estar fora do sistema, não fazer parte do sistema. Pode haver vários participantes realizando funções do sistema, com prioridade

Ao mesmo tempo, o principal objetivo do desenvolvimento de casos de uso é encontrar os principais participantes.

A análise e a descoberta dos atores do sistema podem ser auxiliadas pelas seguintes perguntas: Quem usa o sistema? Quem instalou esse sistema? quem começou

mover o sistema? Quem mantém esse sistema? Quem desliga este sistema? Quais sistemas usam este sistema? quem recebe cartas deste sistema

interesse? Quem fornece informações para este sistema?

◦ Exemplo:

Tomamos como exemplo o sistema de fórum que está sendo desenvolvido atualmente e obtivemos os seguintes requisitos do usuário no estágio inicial:

▪Cadastre-se e faça login

Lista de postagens , postagens de postagens, postagens de exclusão, postagens de respostas e outras funções.

▪ Oferece suporte à exibição/edição da página inicial pessoal e ao upload de avatar.

▪ Suporte à classificação de postagens por fórum.

▪ Suporte para postar emoticons de imagem

▪ Suporte a mensagens privadas no site

▪ Os administradores podem adicionar/excluir/modificar seções

▪ O administrador pode gerenciar todas as postagens

Com base na descrição dos requisitos acima, dois participantes podem ser claramente mencionados, um é um administrador e o outro é um usuário comum.

Mesclar requisitos para obter casos de uso

Uma vez que os atores tenham sido encontrados, o próximo passo é percorrer os atores e identificar casos de uso para cada ator.

Primeiro, atribua os requisitos obtidos aos participantes.Por exemplo, usuários comuns podem se registrar, fazer login e editar informações pessoais.

Informações, postagem, modificação de postagens autopublicadas, envio de mensagens internas, etc., os administradores podem não apenas realizar operações de usuários comuns, mas também gerenciar painéis e assim por diante .

Em segundo lugar, realize operações de mesclagem de requisitos e gere casos de uso. Por exemplo, para postagens, há postagens de publicação, modificação de postagens e exclusão de postagens, que são mescladas em postagens de operação aqui. Nota: O caso de uso não precisa incluir um processo de operação específico (fluxo de evento), e o fluxo de evento será refletido na descrição detalhada do caso de uso.

Em seguida, os participantes identificados e os casos de uso mesclados são expressos na forma de um diagrama de caso de uso, de modo a obter a estrutura do . Como mostrado na figura abaixo:

Descrição detalhada do caso de uso

A descrição do caso de uso pode ser concluída iterativamente. Primeiro, prepare uma descrição relativamente detalhada para alguns casos de uso importantes. Para os casos de uso sem importância, você pode

Para ser complementado posteriormente, a descrição do caso de uso geralmente inclui o nome do caso de uso, breve descrição, fluxo de eventos, requisitos não funcionais, pré e pós-requisitos.

Configurando condições, pontos de extensão, prioridade.

Tomando como exemplo o pós-lançamento no caso de uso pós-operação, a descrição é a seguinte:

1. Exemplo de nome	publicar uma postagem
2. Breve descrição	O usuário publica uma nova postagem e, ao mesmo tempo, aumenta o número de postagens no fórum correspondente
3. Fluxo de eventos	1. O usuário envia uma solicitação ao sistema para postar uma nova postagem 2. O sistema exibe a interface para edição de novos posts 3. O usuário seleciona a categoria do fórum correspondente, escreve o título e o corpo da postagem e envia 4. O sistema verifica se a categoria, o título e o texto do bloco são válidos 5. O sistema armazena e arquiva as informações inseridas e a postagem é publicada com sucesso
4. Fluxo de evento alternativo	nenhum
5. Requisitos não funcionais	nenhum requesito especial
6. Pré-condições	Os usuários devem fazer login no sistema para verificação de permissão
7. Pós-condições	Modifique o número de postagens no fórum correspondente
8. Pontos de extensão	⽆
9. Prioridade	Mais alto (Satisfação 5, Insatisfação 5)

De acordo com o exemplo de descrição detalhada dos casos de uso acima, pode-se ver que o usuário deve verificar o status de login antes de postar, e a operação de postagem inclui verificação de identidade.

A verificação de identidade também está envolvida em outras operações, então abstraímos um caso de uso de verificação de identidade, usando um diagrama de caso de uso para descrever o caso de uso

A relação entre os exemplos é a seguinte:

Definir classe de conceito

Classe de conceito: um objeto no modelo que pode representar coisas e conceitos.

A principal tarefa do OOA é encontrar os objetos e classes no sistema, e essas classes serão refletidas nas classes de software em OOD e nas classes de implementação específicas em OOP.

classe atual.

Existem muitas maneiras de descobrir classes, entre as quais a sintaxe de frases nominais é a mais amplamente usada, e as etapas específicas são as seguintes:

▪Ler e entender documentos de requisitos ou descrições de casos de uso

▪Selecionar substantivos ou frases nominais e criar uma lista de classe inicial (classe candidata)

▪Divida as classes candidatas em três categorias: classes óbvias, classes obviamente sem sentido e classes incertas

▪ Descartar classes que são obviamente categorias sem sentido

▪ Grupos discutem classes de categoria indeterminada até que sejam mescladas ou ajustadas às outras duas categorias.

De acordo com a seção 4.2.4, o fluxo de eventos do pós-caso de uso pode ser usado para obter uma lista de classes de conceitos candidatos, como segue

Após uma análise simples: tanto a "categoria do fórum" quanto o "número de postagens no fórum" podem ser atribuídos à categoria "fórum", como a categoria "fórum"

atributo; "post title" e "post text" podem ser atribuídos à classe "post" como o atributo da classe "post"; "autoridade

Limit" pode ser atribuído à classe "User" como um atributo da classe "User". Até agora, para o caso de uso de postagens de publicação, três

As categorias são: usuário, fórum e postagem.

Identifique as relações entre as classes

Depois de concluir o trabalho de pesquisa de classe, é necessário esclarecer o relacionamento entre essas classes. O relacionamento entre as classes inclui: associação, dependência, genérico

Eles são representados em UML da seguinte forma:

◦Relacionamento de associação: fornece o relacionamento estrutural entre objetos de diferentes classes, em vez do relacionamento entre classes. Dois objetos geralmente são conectados por verbos, por exemplo, usuário-publicar-publicar; você pode usar Se não houver seta, é considerada como uma relação bidirecional ou uma associação indefinida;

◦ Relação de dependência: duas classes A e B, se mudanças em B podem causar mudanças em A, então diz-se que a classe A é dependente de B, por exemplo, uma classe é um membro de dados de outra classe e uma classe é outra classe Um parâmetro de uma operação de uma classe, etc.;

◦ Relacionamento de agregação: o relacionamento de agregação compartilhado é geralmente referido como relacionamento de agregação, que representa o relacionamento entre o todo e parte da classe, "parcial

"Partes" podem pertencer a diferentes "todos", e os ciclos de vida de "partes" e "todos" podem ser diferentes, por exemplo, carros e rodas

É a relação de agregação. Um carro tem várias rodas. Se o carro estiver quebrado, a roda ainda pode ser usada. Se a roda estiver quebrada, você pode substituí-la por outra;

◦ Relação composta: A relação de agregação de combinação é geralmente chamada de relação de combinação para abreviar. Ela também expressa a relação entre o todo e a parte entre as classes. A diferença da relação de agregação é que a "parte" na relação de combinação pode pertencem apenas a um "todo". A vida das "partes" e do "todo"

O ciclo é o mesmo, por exemplo: uma empresa tem vários departamentos, e existe uma relação de combinação entre eles, uma vez que a empresa fecha, algumas partes deixam de existir ;

◦Relacionamento de implementação: descreve o relacionamento entre classes e interfaces, uma classe pode implementar os métodos declarados na interface;

◦Relacionamento de generalização: Descreve o relacionamento entre a classe pai e a subclasse. O relacionamento de herança é o relacionamento inverso do relacionamento de generalização, ou seja, a subclasse herda e a classe pai é a generalização da subclasse .

Para o caso de uso em que os usuários publicam postagens, depois de determinar o relacionamento entre as classes, os diagramas de classe UML podem ser usados para , conforme mostrado na figura a seguir: os usuários publicam postagens e as postagens são agregadas em seções

Adicione responsabilidades às classes

Depois de encontrar as classes de conceito e resolver o relacionamento entre elas, você pode adicionar responsabilidades às classes, incluindo principalmente dois aspectos:

▪Conhecimento mantido pela classe, ou seja, variáveis ou propriedades de membros

• Tome cuidado para manter os atributos simples, ou seja: defina apenas atributos relacionados às responsabilidades e objetivos do sistema; use classes de dados simples

Definição de tipo; nenhum atributo é definido para associações de classe.

▪ Comportamentos que uma classe pode realizar, ou seja, métodos de membros ou responsabilidades

• Pode ser julgado de acordo com o verbo e depois rastreado, o que é semelhante ao processo de identificação de categorias.

Nesta fase, apenas algumas partes principais, óbvias e relacionadas à regra de negócios são encontradas. Não continue a refinar nesta fase

De acordo com a análise das responsabilidades da classe, elas são expressas em um diagrama de classes da seguinte forma:

Crie um diagrama de interação

O comportamento de vários objetos geralmente é representado por diagramas de interação, o mais comumente usado em UML são os diagramas de sequência, que podem ser usados em praticamente qualquer sistema

Cenas.

Os elementos básicos dos diagramas de sequência são objetos, participantes, linhas de vida, caixas de ativação, mensagens e linhas de mensagens, entre as quais as mensagens são a inspiração dos diagramas de sequência.

alma. Tomando como exemplo o processo de login do usuário, o diagrama de sequência é descrito a seguir:

Especificação de Requisitos de Software

Obtenha casos de uso identificando participantes, mesclando requisitos, refinando descrições de casos de uso, definindo classes conceituais, determinando relacionamentos entre classes e adicionando

Etapas como adicionar responsabilidades e estabelecer diagramas de interação completaram a definição de requisitos e abstraíram coisas do mundo real em classes orientadas a objetos. Ao mesmo tempo, as principais funções e escopo do sistema foram determinados. O trabalho acima é A base para escrever a especificação de requisitos de software, desde que esses requisitos sejam agregados para formar a parte dos requisitos da especificação de requisitos de software.

Como resultado entregue no estágio de análise de requisitos, a especificação de requisitos de software tem um importante significado orientador para o projeto e desenvolvimento do sistema.

Seus componentes específicos, tais como: escopo, documentos de referência, requisitos, regulamentos de elegibilidade, rastreabilidade de requisitos, problemas não resolvidos, notas, apêndices e outros conteúdos relacionados, não serão discutidos aqui, se você estiver interessado Os alunos podem consultar os capítulos relevantes no padrão nacional

Padrão Nacional|GB/T 8567-2006

Explicação detalhada do processo padrão (ciclo de vida) de desenvolvimento de software: siga o padrão, projete sem preocupação

1. Visão geral do ciclo de vida do desenvolvimento de software