Modelagem de Software

UNIDADE CURRICULAR:
MODELAGEM DE
SOFTWARE
PROF. ANDRÉ LUIZ PERIN
AULA 01 - 2020
MODELAGEM DE SOFTWARE
Professores da UC MODELAGEM DE SOFTWARE - Turma
ECP1AN-PLB
◦ André Luiz Perin
◦ Daniel Sant’Anna Consiglieri
Horários da aulas
◦ MATRIZ E2A-2.0:
◦ Noturno: 19:15h às 22:00h (com intervalo)
◦ Intervalo de 15 minutos após a primeira aula
horário
1ª. aula 19:15h - 20:05h
Intervalo 20:05h - 20:20h
2ª. aula 20:20h - 21:10h
3ª. aula 21:10h - 22:00h
Tópicos Geradores
◦ Análise de Problema
◦ Análise de Requisitos
◦ Modelagem Orientada a Objetos
◦ Modelagem de Banco de Dados
Metas de Compreensão
◦ Analisar problemas avaliando as necessidades dos clientes.
◦ Criar a especificação de software, elicitando os requisitos funcionais e não
funcionais do software em conformidade com os requisitos do usuário.
◦ Utilizar ferramentas de prototipagem de software e aplicar os tipos de
prototipagem conforme o projeto.
◦ Criar modelos de sistemas de software utilizando o paradigma orientado a
objetos a partir dos principais diagramas da UML.
◦ Especificar modelos conceituais de banco de dados, analisando aspectos do
mundo real a serem tratados pelos sistemas de informação e representando-
os corretamente de acordo com o metamodelo selecionado e integrando-os
com as diretrizes de administração de dados da organização.
◦ Criar modelos lógicos e físicos de banco de dados de acordo com os
propósitos das necessidades do sistema de informação, especificando
estruturas e mecanismos de armazenamento, busca e recuperação de dados.
Plano de Aula
SEMANA PROFESSORES DATA ATIVIDADES SEMANA PROFESSORES DATA ATIVIDADES
1 André Perin 20/08 Visão geral do conceito de processo de software. 9 Daniel Sant'Anna 16/10 Modelo relacional e normalização
1 Daniel Sant'Anna 21/08 Fundamentos de requisitos e visão geral de técnicas para elicitação. 10 André Perin 22/10 Modelo relacional e normalização
2 André Perin 27/08 Técnicas para elicitação de requisitos. 10 Daniel Sant'Anna 23/10 Modelo entidade relacionamento.
2 Daniel Sant'Anna 28/08 Análise e projeto orientado a objetos. Notação UML. 11 André Perin 29/10 Modelo entidade relacionamento.
3 André Perin 03/09 Modelo de casos de uso (diagrama e especificação). User stories. 11 Daniel Sant'Anna 30/10 Modelo relacional e normalização.
3 Daniel Sant'Anna 04/09 Diagrama de atividades. 12 André Perin 05/11 Modelo relacional e normalização.
4 André Perin 10/09 Diagrama de classes. 12 Daniel Sant'Anna 06/11 Modelo lógico e físico de banco de dados.
4 Daniel Sant'Anna 11/09 Diagrama de classes. 13 André Perin 12/11 Modelo lógico e físico de banco de dados.
5 André Perin 17/09 Diagrama de sequência. 13 Daniel Sant'Anna 13/11 Apresentação de Projetos
5 Daniel Sant'Anna 18/09 Diagrama de sequência. 14 André Perin 19/11 Apresentação de Projetos
6 André Perin 24/09 Diagrama de estados. 14 Daniel Sant'Anna 20/11 Feriado - Dia da Consciência Negra
6 Daniel Sant'Anna 25/09 Diagrama de componentes. Diagrama de implantação. 15 André Perin 26/11 Apresentação de Projetos
7 André Perin 01/10 Projeto - parte 1 15 Daniel Sant'Anna 27/11 Apresentação de Projetos
7 Daniel Sant'Anna 02/10 Projeto - parte 1 16 André Perin 03/12 Apresentação de Projetos
8 André Perin 08/10 Análise e projeto de banco de dados. Modelo entidade relacionamento. 16 Daniel Sant'Anna 04/12 Apresentação de Projetos
8 Daniel Sant'Anna 09/10 Análise e projeto de banco de dados. Modelo entidade relacionamento. 17 André Perin 17/12 Revisão de Notas e Faltas
André Perin 15/10 Recesso - Dia do Professor 17 Daniel Sant'Anna 18/12 Encerramento
Bibliografia básica
◦ MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0. São
Paulo: Pearson Education, 2004.
◦ RAMAKRISHNAN, Raghu; GEHRKE, Johannes.Sistemas de
Gerenciamento de Bancos de Dados. 3. edição. Porto Alegre:
Bookman, 2007.
◦ PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. Uma
abordagem profissional. 8a. Ed. Bookman, 2016.
Bibliografia complementar
◦ SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson
Prentice Hall, 2011.
◦ PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2.
ed. São Paulo: Prentice Hall, 2004.
◦ LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e
ao projeto orientados a objetos e desenvolvimento iterativo. 3. ed
Porto Alegre: Bookman, 2007.
◦ FOWLER, Martin; SCOTT, Kendall. UML essencial: um breve guia para a
linguagem-padrão de modelagem de objetos. 3ª. ed. Porto Alegre:
Bookman, 2004.
◦ HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto
Alegre: Bookman, 2011.
Critérios de atribuição da nota final e de aprovação:
◦ A nota final do semestre será composta pela soma das notas A1+A2+A3, onde
◦ A1 – Avaliação dissertativa = 30 pontos.
◦ A2 – Avaliação com questões de múltipla escolha = 30 pontos.
◦ A3 – Avaliação de desempenho = 40 pontos.
◦ Para aprovação, a nota final deverá ³70 e a frequência ³75% da Carga Horária
da Unidade Curricular.
◦ Obs: Caso a frequência do aluno seja <75%, ele estará reprovado, independentemente da nota.
◦ Avaliação Integrada:
◦ O aluno que tiver frequência de ³75% e nota <70 pontos poderá realizar a Avaliação Integrada (AI).
◦ A AI valerá 30 pontos e a nota, se maior, substituirá a menor das notas entre a A1 e a A2.
◦ Caso a nota da AI, por ser maior, substitua a nota da A1 ou da A2, a soma das três notas (A1+A2+A3)
deverá ser 70 pontos ou mais, para a aprovação.
◦ Se a nota da AI for inferior à nota da A1 e, também, da A2, não haverá substituição e o aluno estará
reprovado na Unidade Curricular.
Objetivos da semana
◦ Compreender o que é a engenharia de software e porque ela é
importante.
◦ Compreender que o desenvolvimento dos diferentes tipos de sistema
de software pode exigir diferentes técnicas de engenharia.
◦ Compreender os modelos de processo de software.
◦ Conhecer três modelos genéricos de processo de software e sua
aplicação.
◦ Conhecer as atividades de processo fundamentais da engenharia de
requisitos, do desenvolvimento, dos testes e da evolução de software.
◦ Compreender os fatores que afetam a qualidade do processo.
Introdução
◦ O que é software?
◦ Podemos dizer que software é:
1. Instruções (programas de computador) que, quando executadas, fornecem os
recursos, funções e desempenho desejados.
2. Estruturas de dados que permitem aos programas manipular adequadamente as
informações.
3. Documentação que descreve a operação e o uso dos programas.
Introdução
◦ Software
◦ É desenvolvido ou projetado, não é fabricado no sentido clássico.
◦ Não "se desgasta".
◦ Embora a indústria esteja se movendo em direção ao desenvolvimento baseado em
componentes, a maioria dos softwares continua a ser construída sob encomenda.
Introdução Taxa de
curva
real
aumento da taxa de
falha devido a
falhas
◦ Software efeitos colaterais
◦ Desgaste x Deterioração
mudança
curva ideal
Fonte: Roger Pressman. Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2014)
Tempo
Introdução
◦ Aplicações de Software
◦ Software de sistema
◦ Software aplicativo
◦ Software de engenharia / científico
◦ Software embutido
◦ Software de linha de produto
◦ Aplicativos da Web / móveis (Web Apps / Mobile Apps)
◦ Software de IA (robótica, redes neurais, jogos)
Introdução
◦ Software legado
◦ Um sistema antigo que permanece em operação em uma organização.
◦ Por que deve haver mudanças?
◦ O software deve ser adaptado para atender às necessidades de novos ambientes de
computação ou tecnologia.
◦ O software deve ser aprimorado para implementar novos requisitos de negócios.
◦ O software deve ser estendido para torná-lo interoperável com outros sistemas ou
bancos de dados mais modernos.
◦ O software deve ser reprojetado para torná-lo viável em um ambiente de rede.
Introdução
◦ Web Apps
◦ São muito mais do que arquivos de hipertexto com algumas imagens.
◦ São ampliados com ferramentas como XML e Java para permitir aos engenheiros da
Web, incluindo capacidade de computação interativa.
◦ Podem ter capacidade autônoma para usuários finais ou pode serem integrados a
bancos de dados corporativos e aplicativos de negócios.
◦ As tecnologias da web semântica (Web 3.0) evoluíram para aplicativos corporativos e
de consumo sofisticados que abrangem bancos de dados semânticos que requerem
links da web, representação de dados flexível e interfaces de programação de
aplicativos (APIs) para acesso.
◦ A natureza estética do conteúdo continua sendo um determinante importante da
qualidade de um WebApp.
Introdução
◦ Mobile Apps
◦ Funcionam em plataformas móveis, como telefones celulares ou tablets.
◦ Contém interfaces de usuário que usam características do dispositivo e atributos de
localização
◦ Muitas vezes fornecem acesso a uma combinação de recursos baseados na web e
processamento de dispositivos locais e capacidades de armazenamento.
◦ Fornecem recursos de armazenamento persistente dentro da plataforma.
Introdução
◦ Mobile Apps x Web Apps
◦ Um aplicativo da web móvel permite que um dispositivo móvel acesse o conteúdo
baseado na web usando um navegador projetado para acomodar os pontos fortes e
fracos da plataforma móvel.
◦ Um aplicativo móvel pode obter acesso direto ao hardware encontrado no dispositivo
para fornecer processamento local e recursos de armazenamento.
◦ Com o passar do tempo, essas diferenças desaparecerão.
Introdução
◦ Computação em nuvem
◦ Fornece armazenamento de dados distribuídos
e recursos de processamento para dispositivos
de computação em rede.
◦ Os recursos de computação residem fora da nuvem
e têm acesso a uma variedade de recursos dentro
da nuvem.
◦ A computação em nuvem requer o desenvolvimento
de uma arquitetura contendo serviços de front-end
e back-end.
◦ Os serviços de front-end incluem os dispositivos cliente
e software de aplicativo para permitir o acesso
◦ Os serviços de back-end incluem servidores,
armazenamento de dados e aplicativos residentes
no servidor
◦ As arquiteturas de nuvem podem ser segmentadas Fonte: Roger Pressman.
Software Engineering: A
para restringir o acesso a dados privados Practitioner’s Approach,
8/e (McGraw-Hill 2014)
Introdução
◦ Software de linha de produto
◦ É um conjunto de sistemas de software que compartilham um conjunto comum de
recursos e satisfazem as necessidades de um mercado específico.
◦ Esses produtos de software são desenvolvidos usando o mesmo aplicativo e
arquiteturas de dados usando um núcleo comum de componentes de software
reutilizáveis.
◦ Compartilham um conjunto de ativos que incluem requisitos, arquitetura, padrões de
design, componentes reutilizáveis, casos de teste e outros produtos de trabalho
◦ Permite o desenvolvimento de muitos produtos que são projetados, capitalizando a
semelhança entre todos os produtos da linha de produtos
Introdução
◦ Características dos Aplicativos Web
◦ Orientado por dados
◦ A principal função de muitos WebApps é usar hipermídia para apresentar conteúdo
de texto, gráficos, áudio e vídeo ao usuário final.
◦ Conteúdo sensível
◦ A qualidade e a natureza estética do conteúdo continuam sendo um determinante
importante da qualidade de um WebApp.
◦ Evolução contínua
◦ Ao contrário do software de aplicativo convencional que evolui ao longo de uma
série de lançamentos planejados e cronologicamente espaçados, os aplicativos da
Web evoluem continuamente.
Introdução
◦ Características dos Aplicativos Web
◦ Imediato
◦ Embora o imediatismo - a necessidade imperiosa de colocar o software no mercado
rapidamente - seja uma característica de muitos domínios de aplicativos, os
WebApps geralmente apresentam um tempo de chegada ao mercado que pode ser
de alguns dias ou semanas.
◦ Segurança
◦ Como os WebApps estão disponíveis por meio do acesso à rede, é difícil, senão
impossível, limitar a população de usuários finais que podem acessar o aplicativo.
◦ Estética
◦ Uma parte inegável do apelo de um WebApp é sua aparência.
Engenharia de Software
◦ Algumas realidades:
◦ um esforço concentrado deve ser feito para entender o problema antes que uma
solução de software seja desenvolvida.
◦ O design torna-se uma atividade fundamental.
◦ O software deve apresentar alta qualidade.
◦ O software deve ser sustentável.
Engenharia de Software
◦ Definição:
◦ Engenharia de software é o estabelecimento e uso de princípios sólidos de engenharia
para obter software econômico que seja confiável e funcione de forma eficiente em
máquinas reais.
◦ IEEE:
◦ Engenharia de software é a aplicação de uma abordagem sistemática, disciplinada e
quantificável para o desenvolvimento, operação e manutenção de software; isto é, a
aplicação da engenharia ao software, e o estudo de suas abordagens.
Processo de Software
◦ Estrutura do processo
◦ Atividades
◦ Comunicação
◦ Planejamento
◦ Modelagem
◦ Análise de requisitos
◦ Projeto
◦ Construção
◦ Geração de código
◦ Testes
◦ Operação (Deployment)
◦ Atividades “guarda-chuva”
◦ Acompanhamento e controle de projetos de software
◦ Gerenciamento de riscos
◦ Garantia de qualidade de software
◦ Revisões técnicas
◦ Medição
◦ Gerenciamento de configuração de software
◦ Gestão de reutilização
◦ Preparação e produção de produtos de trabalho
◦ Adaptação de um Modelo de Processo
◦ o fluxo geral de atividades, ações e tarefas e as interdependências entre elas
◦ o grau em que as ações e tarefas são definidas dentro de cada atividade da estrutura
◦ o grau em que os produtos de trabalho são identificados e necessários
◦ a maneira como as atividades de garantia de qualidade são aplicadas
◦ a maneira como as atividades de rastreamento e controle do projeto são aplicadas
◦ o grau geral de detalhe e rigor com que o processo é descrito
◦ o grau em que o cliente e outras partes interessadas estão envolvidos com o projeto
◦ o nível de autonomia dado à equipe de software
◦ o grau em que a organização da equipe e as funções são prescritas
Essência da Engenharia de Software
◦ Compreender o problema
◦ Comunicação e análise
◦ Planejar a solução
◦ Modelagem e projeto de software
◦ Executar o plano
◦ Geração de código
◦ Examinar o resultado
◦ teste e garantia da qualidade
Princípios Gerais da Engenharia de Software (Hooker)
◦ 1: A razão pela qual tudo existe
◦ 2: KISS (Keep It Simple, Stupid!)
◦ 3: Manter a Visão
◦ 4: O que você produz, outros consumirão
◦ 5: Esteja aberto para o futuro
◦ 6: Planeje com antecedência para reutilização
◦ 7: Pense!
Ambiente de Projeto de Software
◦ Como tudo começa:
◦ Cada projeto de software é apressado por alguma necessidade comercial:
◦ a necessidade de corrigir um defeito em um aplicativo existente.
◦ a necessidade de adaptar um "sistema legado" a um ambiente de negócios em
mudança.
◦ a necessidade de estender as funções e recursos de um aplicativo existente.
◦ a necessidade de criar um novo produto, serviço ou sistema.
Modelos de Processo de Software
◦ Os modelos de processo genéricos apresentados aqui são:
◦ Modelo em cascata
◦ Desenvolvimento incremental
◦ Integração e configuração
◦ Na prática:
◦ A maior parte dos processos de software se baseia em um modelo genérico, mas
frequentemente incorpora características de outros modelos.
◦ Vale particularmente para a engenharia dos grandes sistemas. Neles, faz sentido
combinar algumas das melhores características de todos os processos genéricos.
◦ Modelo Cascata
Definição de
Requisitos
Projeto do Sistema e
do Software
Implementação e
Testes Unitários
Integração e Testes
do Sistema
Operação e
Manutenção
REF.: ENGENHARIA DE SOFTWARE, IAN SOMMERVILLE, 9ª ED.
◦ Desenvolvimento incremental
Atividades simultâneas
Especificação Versão Inicial
Descrição Desenvolvimento
Versões
do Esboço Intermediárias
Validação Versão Final

◦ Engenharia de software orientada para o reuso (integração e
configuração):

Atividades do processo
◦ Os processos de software reais são sequências intercaladas de
atividades técnicas, colaborativas e gerenciais, cujo objetivo
global é especificar, projetar, implementar e testar um sistema de
software.
◦ As quatro atividades de processo básicas são:
1. Especificação
2. Desenvolvimento
3. Validação
4. Evolução
Atividades do processo
◦ Especificação de software, onde os clientes e engenheiros
definem o software que deve ser produzido e as restrições sobre
o seu funcionamento.
◦ Desenvolvimento de software, em que o software é projetado e
programado.
◦ Validação de software, em que o software é verificado para
garantia de atender ao que o cliente necessita.
◦ Evolução de software, em que o software é modificado para
refletir as mudanças de requisitos do cliente e do mercado.
Melhoria de processo
◦ Ciclo de melhoria do processo
Melhoria de processo
◦ Níveis de maturidade Nível 5
Em otimização
Nível 4
Gerenciado
quantitativamente
Nível 3
Definido
Nível 2
Gerenciado
Nível 1
Inicial

Modelagem de Software

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelagem de Software

Enviado por

Direitos autorais:

Formatos disponíveis

UNIDADE CURRICULAR:

Fonte: Roger Pressman. Software Engineering: A

Especificação Versão Inicial

Validação Versão Final

REF.: ENGENHARIA DE SOFTWARE, IAN SOMMERVILLE, 8ª ED.

REF.: ENGENHARIA DE SOFTWARE, IAN SOMMERVILLE, 9ª ED.

Você também pode gostar