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 ObjetosProf. Eliseu Castelo Branco Jr.,PMP,MSc.ecastelob@gmail.com

2. Conceitos de Orientação a ObjetosVisão Geral da UMLDiagrama de Caso de UsoDiagrama de ClassesDiagrama de ObjetosDiagramas de InteraçãoDiagrama de EstadoDiagrama de AtividadesDiagramas de ImplementaçãoEmenta da Disciplina

3. Cronograma de Aulas

4. Provas sobre conteúdo teórico da disciplina (Av1, Av2, Av3)Trabalhos de pesquisa publicados na InternetDocumentos de Análise e Projeto de software entreguesExercícios realizados em sala de aulaOBS: 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 pessoasErros 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 objetoObjetos realizam tarefas através da requisição de serviços a outros objetosCada objeto pertence a uma classeA classe é um repositório para comportamento associado ao objetoClasses são organizadas em hierarquiasParadigma 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 FinanceiraClasse BancosClasse Rendas Diversas Classe Contas a PagarClasse Receitas DiversasSubsistema Contas a Pagar

31. Classe BancoAtributosMétodos

32. O que é Análise e Projeto?Análise — “o quê”Investigação do problema e dos requisitosProjeto — “como”Descrição de uma solução lógicaRequisitosCasos de usoRestriçõesVocabulárioObjetosArquiteturaInstalação & OperaçãoInterface do usuário

33. Conceitode domínio Representaçãona análise Representaçãono projetoLivroLivrotítulotítuloimprimir()public class Livro{public void imprimir();private String titulo;}Representaçãono códigoRepresentação de um Conceito na APOOEx.: O conceito “Livro” em um sistema de biblioteca

34. Diagramas de classes de projeto, diagramas de colaboraçãoAtribuição de responsabilidades, projeto das interaçõesQuem é responsável por o quê? Como eles interagem?Uma Analogia — Organizando os Negócios de uma Empresa DocumentosAssociadosAPOOAnalogiaCasos de usoAnálise de requisitosQuais são os processos de negócio?Modelo conceitualAnálise do domínioQuais são os papeis dos empregados?

35. Um Exemplo — Jogo de DadosObjetivo: ganha o jogo o jogador que rolar dois dados e tirar seteModelagem na APOOCasos de usoDescrições narrativas de processos do domínio no formato de prosa estruturadaEx.: Caso de uso:Atores:Descrição:JogarJogadorEste caso de uso começa quandoo jogador rola os dados. Se o totaldos dados for sete, o jogador ganha;do contrário, ele perde.

36. Um Exemplo — Jogo de DadosModelagem na APOO (cont.)Modelo conceitualConceitos, atributos, e associações que são considerados importantes no domínio da aplicaçãoEx.:Um modelo conceitual descreve conceitos do mundo real, não componentes de software!JogadorDado21Rolanomevalor21Joga1JogoDeDados1Inclui

37. Um Exemplo — Jogo de DadosModelagem na APOO (cont.) Diagramas de colaboraçãoAlocação de responsabilidades para objetos ilustrando como eles interagem via mensagensMostram o fluxo de mensagens entre instâncias e a invocação de métodosEx.:joga()1: r1 := rola():Jogadord1 : Dado2: r2 := rola()d2 : Dado

38. Um Exemplo — Jogo de DadosModelagem na APOO (cont.) Diagramas de classes de projetoComo os objetos (de software) se conectam? Quais são os métodos de uma classe?Ex.:JogadorDadoRolavalornome21rola()joga()12Joga1JogoDeDadosInclui1inicializa()

39. APOO X APEMetodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposiçãoSistema deBibliotecaDecomposição por objetos ou conceitosDecomposição por funções ou processosA&P Orientados a ObjetoA&P EstruturadosSistemaCatálogoBibliotecárioRegistraEmpréstimosLivroAdicionaRecursosReportaMultasBiblioteca

40. A Linguagem de Modelagem Unificada — UMLA UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projetoA notação (a própria UML) é relativamente trivialMuito mais importante: habilidade para modelar com objetosSó aprender a notação UML não ajudaA UML não éum processo ou metodologiaAPOOregras de projeto

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

43. Processo de DesenvolvimentoOrganização das atividades relacionadas à produção e manutenção de sistemas de softwareÚtil, mas um fator de segunda ordemO principal: equipe qualificadaBoa equipe + bom processo = menor riscoO 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 atividadesArtefatos (*) : Pedaço físico da informação usado ou produzido durante o desenvolvimento do sistemaAtividadesCasos de UsoClassesClasses ativasColaboraçãoComponenteEstadoInteraçãoInterfaceElementos básicos do modelo UML

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