Embed Size (px)
Citation preview
Gerenciando a Complexidade: Sistemas de Software
u Complexidade dos sistemas de software
u Estrutura
u Decomposição
u Abstração
u Hierarquia
u Projeto de sistemas complexos
2
Software - Complexidade
u Software Simples x Software Complexo u Simples: scripts de configuração, algumas aplicações móveis etc.
u Propósito limitado
u Ciclo de vida geralmente curto
u Criados por uma ou poucas pessoas
u Complexos: reserva de passagens aéreas, sistemas de venda online etc. u Escopo de funcionalidades grande
u Desenvolvimento envolve muitas pessoas
u Ciclo de vida longo
3
Software - Complexidade
u Sistemas de software complexos u Todas os detalhes de um projeto de software não são
dominados por uma só pessoa
u Complexidade pode ser gerenciada, não eliminada
u A complexidade de um sistema de software advém do domínio do problema a que este se destina
u Desenvolvedor interpreta requisitos e implementa – não entende do domínio u Captura de requisitos é uma atividade difícil
u Requisitos evoluem
4
Software – Complexidade Inerente
u Dificuldade de se gerenciar o desenvolvimento de sistemas de software
u Sistemas com milhares de linhas de código são comuns
u Um mesmo problema possui várias soluções – qual a melhor?
u Software - Ilusão da simplicidade
5
Software – Complexidade Inerente
u Sistemas de software podem entrar em colapso se não gerenciados
u Em diferentes momentos: durante o projeto, durante a utilização etc.
u Quanto mais complexo o sistema, maior a chance de um colapso
u Negociação de requisitos com usuários/clientes delimita o escopo de funcionalidades
6
Negociação de requisitos
u Nem sempre a solicitação por uma funcionalidade possui um embasamento ‘lógico’
u Nem sempre o usuário/cliente sabe exatamente o que quer
u Muitas vezes a construção de um sistema parte da formalização de processos
8
9
10
11
Gerenciando a Complexidade
u Projetos de Software, quando não gerenciados adequadamente... u Atrasam
u Estouram orçamento
u Não atendem os requisitos elencados em conjunto com os usuários/clientes
u Gerenciar a complexidade u Entender o necessário acerca do domínio do problema
u Traduzir em informação útil para construção de um sistema de software
12
Hierarquia
u Sistemas Complexos u Estrutura hierárquica
u Diferentes níveis de abstração
u Decomposição u Sistema de Banco de Dados
u Computador Pessoal (placa mãe -> processador -> registradores...)
u Sistemas complexos: u Estrutura de seres vivos (plantas, animais...)
u Estrutura da matéria (ligas, moléculas...)
13
Estrutura de sistemas complexos u Complexidade é gerenciada através da construção de uma
representação estrutural hierárquica u Sistema complexo = conjunto de subsistemas inter-relacionados
u Projeto definirá quais agrupamentos lógicos compõem o sistema e como estes se relacionam
u Estrutura lógica hierárquica define como são os relacionamentos
u Todo-parte
Motor
Carro
Sistema de pistões
14
http://necsi.edu/projects/mclemens/
15
Estrutura de sistemas complexos
u Abstrações e mecanismos comuns facilitam
u Exemplos u Joystick de videogame controla diferentes jogos
u Controle de navegação de veículos como aviões e carros (oferecem o mesmo conjunto de controles em diferentes modelos)
u Hierarquia todo-parte - composição
u Hierarquia “tipo de” - herança
16
Decomposição orientada a objetos
u Sistema = conjunto de subsistemas inter-relacionados
u Sistema possui uma estrutura lógica hierarquizada
u Abstrações chave: classes e objetos u Cada objeto é uma entidade com um
comportamento bem definido
u Sistema = objetos que colaboram entre si
17
Decomposição orientada a objetos
u Vantagens: u Organizar a complexidade através de
abstrações e mecanismos comuns u Facilita a reutilização de mecanismos
comuns u Favorece o desenvolvimento incremental
do sistema (evolução)
18
Decomposição orientada a objetos
u Abstração u Modelo idealizado que ignora alguns detalhes não essenciais
u Retirar do domínio do problema os detalhes relevantes e representar na linguagem da solução
19
Projeto de sistemas complexos
u Especificação funcional (requisitos funcionais)
u Limitações (hardware e software) u Desempenho e utilização de recursos
(requisitos não funcionais) u Satisfazer orçamento e prazos u Disponibilidade de equipe e instrumental
20
Projeto de sistemas complexos
u Notação para descrição da solução proposta u Exemplo: UML (Unified Modeling Language)
u Processo de desenvolvimento u Exemplo: RUP
u Ferramentas u Exemplo: IDE, Sistemas para Controle de versão, Bug tracking
etc.
u Manutenção de software é uma tarefa complexa e cara
u Quanto mais cedo se antecipa/corrige um erro, melhor
21
22
Orientação a objetos
u Orientação a Objetos (OO) é uma abordagem de programação que procura explorar nosso lado intuitivo.
u Os objetos usados para construir softwares são análogos aos objetos existentes no mundo real.
u Objetos que compartilham uma mesma interface (respondem as mesmas mensagens) são agrupados em classes. u Objetos são entidades dinâmicas, com ciclo de vida
definido
Orientação a objetos
u No enfoque de OO, a entidade mínima do processo de computação - os objetos - trocam mensagens entre si. u Chamada por funções (métodos) oferecidos pelos
objetos
u Modificam o estado dos objetos (valor de seus atributos)
Linguagens orientadas a objeto
u OO surgiu no final da década de 60 (!), através da linguagem Simula u Em 1967 a linguagem Simula já incorporava classes e
o conceito de herança
u O termo “orientação a objetos” é introduzido somente em 1983, através da linguagem SmallTalk u Paradigma se estabeleceu durante a década de 80
u Linguagens: Ada, Eiffel, Object Pascal (Delphi/Kylix), Common Lisp, C++
u Mais tarde: Java, Python, Perl, Ruby
Linguagens orientadas a objeto
u Linguagens puras, são aquelas onde tudo é tratado consistentemente como um objeto, desde as primitivas até caracteres e pontuação (Smalltalk, Eiffel, Ruby).
u Algumas linguagens são projetadas para OO, mas com alguns elementos procedimentais (Java, Python)
u Linguagens originalmente procedurais que evoluíram, como C++, Fortran etc.
Referências
u Notas de aula do Prof. Renato Maia (Unimontes)
u Notas de aula do Prof. Renato Mesquita (UFMG)
u Notas de aula da Profa. Elisa Yumi Nakagawa
27
Próximas aulas
u Projeto de Software
u Gerência de Versão de software (git)
u Revisão de C
u Linguagem C++
u Motivação para o uso de C++ para o aprendizado de POO
u C++ versus C
u Quando usar C e quando usar C++
u C++ versus Java
u Sintaxe básica de C++
28
