O documento discute conceitos de modelagem orientada a objetos e a linguagem UML, incluindo diagramas e elementos básicos. Também aborda desafios no desenvolvimento de sistemas embarcados e a importância da adoção da UML.

1. Análise Orientada a Objetos Prof. Eliseu Castelo Branco Jr.,PMP,MSc. ecastelob@gmail.com

2. Conceitos de Orientação a Objetos Visão Geral da UML Diagrama de Caso de Uso Diagrama de Classes Diagrama de Objetos Diagramas de Interação Diagrama de Estado Diagrama de Atividades Diagramas de Implementação Ementa da Disciplina

3. Cronograma de Aulas

4. Provas sobre conteúdo teórico da disciplina (Av1, Av2, Av3) Trabalhos de pesquisa publicados na Internet Documentos de Análise e Projeto de software entregues Exercícios realizados em sala de aula OBS: mínimo de 75% de presença em sala de aula necessário para aprovação na disciplina. Avaliações

5. Sistemas de software são complexos. O uso de modelos auxilia na compreensão de conceitos complexos. Introdução

6. O desenvolvimento de um sistema envolve grande quantidade de atividades e pessoas Erros são inevitáveis e se identificados nos modelos sua correção é mais fácil e barata. Introdução

7. O uso de modelos reduz o custo do desenvolvimento de sistemas. O modelo permite prever o comportamento do sistema no futuro. Introdução

8. A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares. O que é modelagem de software?

9. “Paradigma é a forma de abordar um problema” Princípios: Qualquer coisa é um objeto Objetos realizam tarefas através da requisição de serviços a outros objetos Cada objeto pertence a uma classe A classe é um repositório para comportamento associado ao objeto Classes são organizadas em hierarquias Paradigma da Orientação a Objetos

10. O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados OBJETOS. Cada objeto realiza tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada. Paradigma da Orientação a Objetos

11. Tipos de Sistemas

12. O Sistema contem subsistemas

28. Subsistemas de um Sistema de Informação

29. Módulos do Sistema (subsistemas)

30. Classe Movimentação Financeira Classe Bancos Classe Rendas Diversas Classe Contas a Pagar Classe Receitas Diversas Subsistema Contas a Pagar

31. Classe Banco Atributos Métodos

32. O que é Análise e Projeto? Análise — “o quê” Investigação do problema e dos requisitos Projeto — “como” Descrição de uma solução lógica Requisitos Casos de uso Restrições Vocabulário Objetos Arquitetura Instalação & Operação Interface do usuário

33. Conceito de domínio Representação na análise Representação no projeto Livro Livro título título imprimir() public class Livro { public void imprimir(); private String titulo; } Representação no código Representação de um Conceito na APOO Ex.: O conceito “Livro” em um sistema de biblioteca

34. Diagramas de classes de projeto, diagramas de colaboração Atribuição de responsabilidades, projeto das interações Quem é responsável por o quê? Como eles interagem? Uma Analogia — Organizando os Negócios de uma Empresa Documentos Associados APOO Analogia Casos de uso Análise de requisitos Quais são os processos de negócio? Modelo conceitual Análise do domínio Quais são os papeis dos empregados?

35. Um Exemplo — Jogo de Dados Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete Modelagem na APOO Casos de uso Descrições narrativas de processos do domínio no formato de prosa estruturada Ex.: Caso de uso: Atores: Descrição: Jogar Jogador Este caso de uso começa quando o jogador rola os dados. Se o total dos dados for sete, o jogador ganha; do contrário, ele perde.

36. Um Exemplo — Jogo de Dados Modelagem na APOO (cont.) Modelo conceitual Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação Ex.: Um modelo conceitual descreve conceitos do mundo real, não componentes de software! Jogador Dado 2 1 Rola nome valor 2 1 Joga 1 JogoDeDados 1 Inclui

37. Um Exemplo — Jogo de Dados Modelagem na APOO (cont.) Diagramas de colaboração Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens Mostram o fluxo de mensagens entre instâncias e a invocação de métodos Ex.: joga() 1: r1 := rola() :Jogador d1 : Dado 2: r2 := rola() d2 : Dado

38. Um Exemplo — Jogo de Dados Modelagem na APOO (cont.) Diagramas de classes de projeto Como os objetos (de software) se conectam? Quais são os métodos de uma classe? Ex.: Jogador Dado Rola valor nome 2 1 rola() joga() 1 2 Joga 1 JogoDeDados Inclui 1 inicializa()

39. APOO X APE Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição Sistema de Biblioteca Decomposição por objetos ou conceitos Decomposição por funções ou processos A&P Orientados a Objeto A&P Estruturados Sistema Catálogo Bibliotecário Registra Empréstimos Livro Adiciona Recursos Reporta Multas Biblioteca

40. A Linguagem de Modelagem Unificada — UML A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto A notação (a própria UML) é relativamente trivial Muito mais importante: habilidade para modelar com objetos Só aprender a notação UML não ajuda A UML não é um processo ou metodologia APOO regras de projeto

41. Origem e Evolução da UML UML 1.1 Industrialização (Set’97) UML 1.0 Padronização (Jan’97) Parceiros da UML UML 0.9 & 0.91 Unificação II (Out’96) Unified Method 0.8 Unificação I (Out’95) Booch’93 OMT-2 Outros métodos OOSE Booch’91 OMT-1 Fragmentação

43. Processo de Desenvolvimento Organização das atividades relacionadas à produção e manutenção de sistemas de software Útil, mas um fator de segunda ordem O principal: equipe qualificada Boa equipe + bom processo = menor risco O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria

44. Sol, Mar e UML

45. Visões da UML

46. Uma série de pesquisas (www.embeddded-forecast.com) tem mostrado que muitos projetos de software embarcados são entregues com atraso ou cancelados. Em média, observou-se que mais de 50% dos projetos têm seus cronogramas atrasados em pelo menos quatro meses e cerca de 11% são cancelados.

47. O custo dos atrasos pode ser significativo. Por exemplo, no setor de aviônicos o custo dos atrasos é estimado de 50.000 a 300.000 dólares por mês. Outro problema apontado é o nível de conformidade do produto final com as especificações. Identificou-se que pelo menos 30% dos projetos não alcançavam 50% das especificações propostas de performance ou funcionalidade.

48. À medida que os sistemas embarcados aumentam em complexidade, esta situação tende a piorar. A pesquisa mostrou também que adoção de UML (UnifiedModelingLanguage) ainda não é uma prática comum.

49. Ações (*) : unidade básica de especificação de comportamento. Ações estão contidas em atividades Artefatos (*) : Pedaço físico da informação usado ou produzido durante o desenvolvimento do sistema Atividades Casos de Uso Classes Classes ativas Colaboração Componente Estado Interação Interface Elementos básicos do modelo UML

50. No Nota Pacote Partes (*) Portas (*) Estereótipos (*) Valores de etiqueta (*) Restrições (*) Elementos básicos do modelo UML