Modelagem e Projeto de Sistemas de Software Orientados

a Objetos baseado com Unified Modeling Language (UML)

1. Introdução
P01 (Desenvolvimento de SW) [1]
=> É complexo em escala
=> Tarefas de projeto de SW como planejamento e análise são fundamentais

P02 (Modelos) [2]

=> São representações idealizadas do sistema
=> Facilitam gerenciamento do processo de SW
=> Geram otimização de tempo e custo (ainda + em times grandes)

P03 [1]–P04 (Projeto e Modelagem de Sistemas)

=> Uso de notações gráficas e textuais
=> Representações de partes essenciais do sistema
=> Popularidade do paradigma OO
​ ​=> Obj que fazem tarefas específicas + interações

P05 (Linguagens de Modelagem)

=> Papel crítico no projeto de sistemas
=> Estabelecem padrões de representação para componentes e features
=> Facilitam comunicação entre envolvidos

P06 (UML) [1]

=> Linguagem de modelagem para sistemas OO
=> Provê notações, diagramas e recursos
=> Este documento discute...
P07: Este documento está organizado...

2. Análise de Requisitos
P08 (Engenharia de Requisitos) [2]
=> Requisito de SW: feature que deve ter OU restrição que deve satisfazer
​ ​=> Visa atender necessidades clientes
=> Engenharia de Requisitos
​ ​=> Objetivo: Definir requisitos do sistema
​ ​=> Atividades Principais: Elicitação e Análise de Requisitos
P09 (Elicitação de Requisitos)
=> Objetivo: Descrever propósito do sistema
=> Atividades: Identificação de: atores, use cases, requisitos (func e não-​func)
P10 (Requisitos)
=> Funcionais: funcionalidades do sistema
=> Não-​Funcionais: comportamento do sistema
P11 (FURPS+)
=> Usabilidade: Quão fácil é operar e interpretar saídas sistema/componente
=> Confiabilidade: realizar funções em condições esperadas (e.g., MTTF)
=> Desempenho: atributos quantificáveis do sistema (e.g., latência,throughput)
=> Suportabilidade: facilidade de fazer alterações após implantação

P12 (Análise de Requisitos)

=> Objetivo: validar/corrigir/esclarecer especificação de requisitos
=> Envolve a criação de modelos de análise
​ ​=> Formalizam a especificação de requisitos
​ ​=> Checam se o sistema está correto/completo/consistente/não ambíguo

P13 (Elicitação versus Análise + Modelo de Análise)

=> Elicitação: obtenção de requisitos
=> Análise: estruturação e formalização dos requisitos
=> Modelo de Análise:
​ ​=> Modelo funcional: diagramas de casos de uso
=> Modelo de objeto: diagramas de classe
=> Modelo dinâmico: diagramas de máquina de estado e sequência
P14: A próxima seção detalha...
3. Modelos de Software
P15 (Modelo de Casos de Uso) [1]
=> Representa usos do sistema
=> Perspectiva externa
=> Componentes:
​ ​=> Atores
​ ​=> Casos de uso
​ ​=> Relacionamentos
=> A Figura 1 apresenta...

P16 (Diagramas de Casos de Uso)

=> Representação visual dos
requisitos funcionais
=> Interação entre usuários e
sistema
Fig. 1
P17 (Modelo de Classes) [3]
=> Visão técnica da estrutura do sistema
=> Detalha entidades e funcionalidades
=> Classes, atributos e métodos

P18 (Diagrama de Classes)

=> Representação das entidades do sistema
=> Formato de caixa dividida em três compartimentos
​ ​=> Nome da classe
​ ​=> Atributos
​ ​=> Métodos
=> Notações para especificar aspectos como visibilidade

P19: A Figura 2 apresenta um diagrama de classes...

4. Conclusões P20: Conclusões...

Referências
[1] Eduardo Bezerra. Princípios de Análise e Projeto de Fig. 2
Sistemas com UML. 2007.
[2] Bernd Bruegge e Allen Dutoit. Object Oriented
Software Engineering Using UML, Patterns, and Java.
2009.
[3] Raul Wazlawick. Análises e Projetos de Sistemas de
Informação Orientados a Objetos. 2010.
 Processo e Qualidade de Software: Uma Visão Geral da
Engenharia de Software e Metodologias de Desenvolvimento
1. Introdução
P01 (Demanda por Organização)
=> Integração de software no cotidiano (comunicação social, entretenimento)
=> Demanda crescente (desempenho + confiabilidade)
=> Aumento da complexidade dos sistemas
P02 (ES)
=> Importância de planejamento e sistematização do desenv. de SW
=> ES: recursos p/ criar SW de qualidade
=> Este documento...
P03: Este documento está organizado...
2. ES
P04 (ES) [1]
=> Busca por qualidade
=> Três camadas (Ferramentas,
Métodos, Processos) -> citar Figura 1 Fig. 1
P05 (Ferramentas e Métodos)
=> Ferramentas:
​ ​=> Suporte automatizado ou semiautomatizado para camadas inferiores
=> Métodos (provêm informações técnicas)
​ ​=> Baseiam-​se em princípios norteadores para garantir qualidade de:
​ ​ ​ ​=> análise, modelagem, desenvolvimento, testes e suporte
P06 (Processos)
=> Garantem coesão das camadas de tecnologia
=> Asseguram desenvolvimento racional e dentro do prazo
=> Definem metodologias para entregas e gerenciamento de projetos
3. Modelos de Processo de Software
P07 (ES) [1]
=> Se baseiam em modelos
=> Definem relação entre atividade/modelo e atividade/atividade
=> Seguem fluxos (escalonamento tarefas no tempo)
=> O resto desta seção...
3.1. Cascata
P08–P09 (Cascata)
=> Abordagem sequencial
=> Críticas: falta de flexibilidade
=> Recomendado para projs com req. fixos e estritos
=> Citar Figura 2 [1]

Fig 2.
3.2. Incremental
P10 (Incremental)
=> Sequências lineares escalonadas
=> Incrementos entregáveis
=> Produto essencial -> avaliação -> modificações e novas funcionalidades
=> Citar Figura 3 [1]

3.3. Evolucionário Fig. 3

P11 (Evolucionário)
=> Versões intermediárias
=> Dois tipos principais
(Prototipação e Espiral)

P12 (Prototipação)
=> Ideal para cenários onde:
​ ​=> Usuários têm obj. gerais mas sem detalhamento (imprevisibilidade)
=> Projetos rápidos c/ represent. visíveis do sistema
=> Projetos rápidos -> validação -> refinamento dos requisitos (citar Fig. 4)

P13 (Espiral)
=> Estratégia cíclica e incremental visando redução de riscos
=> Séries de versões evolucionárias
=> Protótipo de alto nível -> versões cada vez mais completas (citar Fig. 5)
 Fig. 5

Fig. 4

4. Metodologias Ágeis
P14 (Movimento Ágil) [2]
=> Manifesto para Desenvolvimento Ágil de Software
=> Pequenos incrementos
=> Feedback contínuo
=> Flexibilidade e adaptação
O restante desta seção...
4.1. Scrum
P15–P16 (Scrum) [3]
=> Colaboração entre equipes
=> Sprints
=> Backlog do produto (gerenciado pelo PO ou PM) e backlog do sprint
=> Reuniões diárias e de retrospectiva (final sprint)

4.2. XP
P17–P19 (XP) [4]
=> Foco em POO
=> Quatro atividades metodológicas:
​=> Planejamento: requisitos -> histórias (descrição, valor de negócio, custo)
​=> Projeto: KISS (reduzir complexidade)
​=> Codificação: Programação em Pares
​=> Testes: Testes automatizados (executados após adições/modificações)
5. Conclusões P20: Conclusões...
[1] Roger Pressman. Engenharia de Software: Uma Abordagem Profissional.
2016.
[2] Kent Beck et al. Manifesto for agile software development. 2001.
[3] Ken Schwaber. SCRUM Development Process. 1997.
[4] Kent Beck. Embracing change with extreme programming. 1999.
 Modelagem e Desenvolvimento de Sistemas Inteligentes
através da Engenharia de Software Orientada a Agentes
1. Introdução
P01 (Inovação Tecnológica) [1]
=> Aumento da demanda por autonomia e autoadaptação
=> Necessidade de SWs que lidam com situações imprevisíveis
P03 (Abordagens Tradicionais e.g. OO) [2]
=> Entidades passivas e falta de:
=> Autonomia: tomar decisões e agir sem supervisão externa
=> Reatividade: perceber o ambiente e responder a estímulos
=> Proatividade: exibir comportamentos orientados a objetivos
P02 (AOSE — Agent-​Oriented SE)
=> SWs c/ características humanas
​ ​=> Capacidades sociais e de tomada de decisões orientadas a objetivos
P04: Este documento está organizado...
2. Agentes de Software
P05–P07 (Agentes) [3]
=> Entidades que realizam tarefas
=> Classificação baseada em: Autonomia e Inteligência
=> Nem todos são intelig./autônomos (Simple Network Management Protocol)
​=> Não escolhe se vai ou não coletar determinados dados (autonomia)
​=> Não muda o comportamento para otimizar algum objetivo (inteligência)

P08 (Social)
=> Há classificação de agentes baseada em hab. sociais
=> Colaboração com outras entidades
=> Comunicação, negociação, compartilhamento de recursos

P09 (SMA)
=> SMA: Interseção entre IA, Sistemas Distribuídos e ES
=> Componentes atuando com autonomia e inteligência

P10–P12 (BDI) [4] (citar Fig. 1)

=> Modelo para agentes racionais (capazes de deliberar sobre decisões com
base em seus modelos simbólicos de mundo)
=> Crenças (Beliefs) - informações sobre o ambiente e agentes
=> Desejos (Desires) - objetivos do agente
=> Intenções (Intentions) - planos de ação para atingir objetivos
P13 (Agentes BDI)
=> São inteligentes e autônomos (capazes de observar o ambiente, estipular e
atualizar seus objetivos e traçar planos de ação de acordo)

P14 (Modelo OO)

=> Ganhou bastante
popularidade
=> UML: padrão para
documentar
visualmente aspectos
de captura de req.,
análise, design e
implantação de SW
P15 (Modelagem Orientada a Agentes)
=> Linguagens (Gaia, Prometheus, TROPOS) c/ limitações
​ ​=> Documentação/especificação, aspectos de MAS não modelados

P16 (AML — Agent Modeling Language)

=> Baseada na Superestrutura da UML 2.0
=> Modela conceitos de MAS (Entidades, abstração e decomposição
comportamental, aspectos sociais e mentais, interações)
=> Entidades fundamentais:
​=> Agente: entidades autônomas que interajem com o ambiente.
​=> Recurso: entidades físicas ou de informação com qnt/cond. de uso, etc.
​=> Ambiente: conjunto de condições lógicas ou físicas.

3. Conclusões P17–P18: Conclusões...

Referências
[1] Michael Luck. Agent-​Oriented Software Engineering IX. 2009
[2] Ali Jazayeri e Ellen Bass. Agent-​Oriented Methodologies Evaluation
Frameworks: A Review. 2020.
[3] Onn Shehory e Arnon Sturm. A Brief Introduction to Agents, em Agent-​
Oriented Software Engineering. 2014.
[4] Michael Bratman. Intention, plans, and practical reason. 1987.
[5] Ivan Trencansky and Radovan Cervenka. The Agent Modeling Language -
AML: A Comprehensive Approach to Modeling Multi-​Agent Systems. 2007.
 Automação de Tarefas Desenvolvimento com
Engenharia de Software Orientada a Modelos
1. Introdução
P01 (ES)
=> Abstração — separação entre elementos:
​ ​=> Essenciais (funcionalidades) e não essenciais (tecnologias, plataforma)
P02 (Não Essenciais)
=> Precisam ser considerados durante o projeto e desenvolvimento
=> Apesar de que: foco inicial nos essenciais (funcionalidades, desempenho)

P03 (Modelos)
=> Modelos: representações de aspectos essenciais
=> Permitem redução de complexidade, e:
​=> Previsão de carac. do sistema
​=> Análise de propriedades de forma mais ágil e menos custosa
P04 (Engenharia Dirigida por Modelos) [1]
=> Provêm recursos p/ criação de modelos c/ representações de SWs
=> Foco: consistência e a qualidade do produto final
P05: Este documento está organizado...
2. Engenharia de Software Orientada a Modelos (ESOM)
P06 (ESOM) [2]
=> Modelos como entidades de primeira classe
​ ​=> Descrevem: arquitetura, req., funcionalidades, comportamento do SW
=> Tipos de Modelos:
​ ​=> Mod. de Requisitos: capturam as necessidades do usuário e as
​ ​expectativas do sistema.
​ ​=> Mod. de arquitetura: definem a estrutura do sistema, incluindo
​ ​componentes, interfaces e relacionamentos.
​ ​=> Mod. de implementação: representam as especificações do código.

P07 (ESOM) [3]

=> Desenvolvida pela Object Management Group (OMG)
=> Apresenta processos e boas práticas para ESOM
=> Aborda limitações da modelagem orientada a objetos (UML)
P08–P09 (Caso de uso) [1] — Citar Fig. 1
=> Automação de tarefas c/ transformações de modelos
=> Processo de geração de código
=> Gerador de código baseado em regras predefinidas
=> Refinamento/compilação/implantação pode ser feito por IDEs tradicio...

Fig. 1

[1] Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-​Driven Software

Engineering in Practice. 2017.
[2] Sami Beydeda, Matthias Book, Volker Gruhn. Model-​Driven Software
Development. 2005.
[3] Thomas Stahl, Markus Völter, Jorn Bettin, Arno Haase, Simon Helsen. Model-​
Driven Software Development. 2005.
 Abordagens Experimentais como Base para Mecanismos
de Melhoria Contínua em Sistemas de Software
1. Introdução
P01 (Demanda Crescente)
=> Aumento da demanda (desempenho/confiabilidade)
=> SWs se tornando mais complexos
=> Necessidade de identificar áreas de melhoria
=> Importância de abordagens de avaliação

P02 (Avaliação) [1]

=> Avaliação é complexa por causa da natur. dinâmica
=> Fatores internos e externos afetando resultados (users, rede, etc.)
=> Preocupação em assegurar consistência/confiabilidade de resultados

P03 (Abordagens Avaliação) [1]

=> Simulação tem menor custo e mais agilidade, mas:
​=> Limitações devido a modelos artificiais e abstrações
=> Importância de avaliações empíricas
​=> Abordagem eficaz para avaliação de sistemas de software

P04: Este documento está organizado...

2. Pesquisa Experimental em Engenharia de Software
P05–P06 (Estudos Empíricos)
=> Exploratórios
​ ​=> Entender fenômenos, situações ou problemas
​ ​=> Entrevistas e estudos observacionais
=> Explanatórios
​ ​=> Relação entre variáveis e teste de hipóteses
​ ​=> Métodos quantitativos e experimentos
P07: O restante desta seção... [2]
2.1. Surveys
P08–P09 (Surveys)
=> Visa: descrever/comp./explicar certos conhec./atitudes/comportamentos
=> Investigação retrospectiva (já está sendo utilizada há algum tempo)
=> Usa entrevistas e questionários
=> Análise e generalização dos resultados
2.2. Estudos de Caso
P10–P12 (Estudos de Caso)
=> Análise de instâncias específicas
=> Analisar atrib. que podem variar dependendo de fatores não identificados
=> Rastrear um atributo específico ou estabelecer relac. entre atributos
2.3. Experimentos
P13–P15 (Experimentos)
=> Testar hipóteses sob condições controladas
=> Grupos experimental (exposto ao estímulo) e de controle (serve p/
controlar explicações plausíveis rivais)
=> Relação antagonal com estudos de caso que usam um único grupo
=> Medir os participantes na variável dependente antes (pré-​teste) e depois
(pós-​teste) que a variável independente (ou estímulo) seja administrada

3. Conclusões P16: Conclusões...

[1] Claes Wholin et al. Experimentation in Software Engineering. 2014.
[2] Guilherme Travassos, Dmytro Gurov e Edgar do Amaral. Introdução à
Engenharia de Software Experimental. 2002.
 Metodologias Ativas para Educação em Engenharia de Software:
Abordagens Inovadoras para Desenvolver as Habilidades do Século XXI
1. Introdução
P01 (Globalização) [1]
=> Globalização->Maior competitividade
=> Importância das Habilidades do século XXI
=> Pensamento crítico, resolução de prob., trabalho em equipe, criatividade
=> Necessidade de revitalização de programas de ensino

P02 (Revital. do Ensino) [2]

=> Constraste Modelo tradicional vs Habilidades Séc. XXI
=> Sintomas: baixo desempenho e evasão escolar
=> Aprendizagem passiva x hab. dinâmicas (pensamento crítico e lógico)
P03 (Pesquisas) [3]
=> Pesq. Educação/Psicologia/Neurociência: proc. aprendizag. é único
=> Aprende-​se o que gera conexões cognitivas e emocionais
=> Preocupação em aproximar teoria e prática profissional

P04 (MAs)
=> Alternativa à exposição monótona
=> Participação efetiva dos alunos
=> Modelo ação-​reflexão-​ação
=> Aprendizagem no próprio ritmo, tempo e estilo
=> Este documento discute...
P05: Este documento está organizado...
2. Metodologias Ativas: Visão Geral e Conceitos
P06–P07 (MAs)
=> Aluno no centro da aprendizagem
=> Participação ativa/colaborativa (alunos aprendem melhor quando
envolvidos ativamente no proc. de aprendiz.)

2.1. ABP
P08–P12 (ABP) [4]
=> Criada na década de 60 (áreas como Med.)
=> Resolução de problemas reais e desenvolvimento de habilidades práticas
=> Exemplo em ES: metodologias ágeis, kanban
=> Prof.->facilitador (feedback); Alunos->resolvedores (teamwork, liderança)
2.2. Ensino Híbrido
P13–P15 (Blended Learning) [5]
=> Combinação de aprendizagem on-​line e presencial
=> Flexibilidade para os alunos
=> Exemplo em ES: aulas práticas presenciais + recursos on-​line (AVAs, etc.)

2.3. Coding Dojo

P16–P18 (Coding Dojo) [6]
=> Aprimoramento de habilidades de programação
=> Kata: duplas de alunos (piloto: escreve código. co-​piloto: observa e auxilia)
=> Randori: os membros da dupla alternam entre as funções em rodadas. Os
demais alunos participam de discussões.
=> Kake: múltiplas duplas simultâneas, menor ociosidade que o Randori. Ao
final de cada rodada, os alunos trocam de função e de dupla.

2.4. Gamificação
P19–P22 (Gamificação) [7]
=> Elementos de jogos (pontuações, rankings, níveis, recompensas, desafios)
=> Aumento da motivação e engajamento
=> Exemplo em ES: jogo que simula um projeto de Dev. Alunos:
devs/PMs/stakeholders (devem trabalhar em equipe)

3. Desafios em Aberto e Oportunidades de Pesquisa

P19–P22 (Gamificação) [7]
=> Falta de infraestrutura adequada
​ ​=> Salas de aula equipadas c/ ferramentas de comunicação e colaboração
=> Formação continuada dos professores
​ ​=> Preparação para aplicação de MAs + fomento especialização/eventos
[1] Bernie Trilling e Charles Fadel. 21st Century Skills: Learning for Life in Our Times. 2009.
[2] Anne-​Kathrin Peters e Arnold Pears. Engagement in Computer Science and IT – What! A Matter
of Identity?. 2013.
[3] Lilian Bacich e José Moran. Metodologias Ativas para uma Educação Inovadora: Uma
Abordagem Teórico-​Prática. 2017.
[4] Ita Richardson e Yvonne Delaney. Problem Based Learning in the Software Engineering
Classroom. 2009.
[5] Fernando Alonso et al. How Blended Learning Reduces Underachievement in Higher Education:
An Experience in Teaching Computer Sciences. 2011.
[6] Géssica Alves, Ayla Rebouças e Pasqueline Scaico. Coding Dojo como Prática de Aprendizagem
Colaborativa para Apoiar o Ensino Introdutório de Programação: Um Estudo de Caso. 2019.
[7] Manal Alhammad e Ana Moreno. Gamification in software engineering education: A systematic
mapping. 2018.