Complexidade do Software• Sistemas de software são complicados• Os requisitos modernos tendem a complicá-

lo cada vez mais:– Alta confiabilidade; – Alto desempenho; – Alto desempenho; – Desenvolvimento rápido e barato

• Precisamos de mecanismos de gerenciamento da complexidade:– Abstração; – Generalização; – Agregação.

O software deve passar uma “ilusão” de simplicidade:

Paradigma Procedural X OO

Procedural OO

tipos de dados classes/TADtipos de dados classes/TAD

variável objeto/instância

função/procedimento operação/serviço

chamada de função passagem de mensagem

Processo Orientado a Objetos

• Baseia-se em objetos e não em procedimentos

• O projetista não inicia o processo com a • O projetista não inicia o processo com a identificação das funções do sistema, mas sim pela identificação dos objetos

Modelo de Objetos

• Idéias Básicas

• Representar o software através de elementos do mundo real:do mundo real:– Entidades físicas

– Entidades abstratas

• Unificação dos conceitos de dados e funções (encapsulamento)

Fundamentos do Modelo de Objetos

• Encapsulamento

• Modularidade• Modularidade

• Abstração de dados

• Hierarquia de Abstração

Encapsulamento– Ocultação de informação (Information Hiden)

– esconder detalhes de um objeto que não contribuem para suas características essenciais

– Separar aspectos de uso de aspectos de implementação

– Um objeto – Um objeto (componente de software) possui uma interface visível e uma parte interna invisível

Modularidade • É a propriedade de construir um sistema através de

módulos altamente coesos e fracamente acoplados.

– Coesão do módulo: interrelação entre seus componentes

– Acoplamento: interdependência entre módulos

Abstração• Concentrar no que é relevante e ignorar detalhes. • Abstração descreve características essenciais do

objeto que o distingue de outros tipos de objetos, e portanto proporciona limites limites conceituais bem definidos, relativo à perspectiva do observador.

Hierarquia de Abstração

• Sistema com muitos detalhes pode ser decomposto numa hierarquia de abstrações.

• Hierarquia permite que • Hierarquia permite que detalhes sejam inseridos de uma modo controlado

• Duas categorias :

Agregação/decomposição

Generalização/especialização

Aprendendo a pensar abstrações

1. Classificação/instanciação - construir uma abstração

2. Agregação/decomposição para construir 2. Agregação/decomposição para construir uma hierarquia de agregação

3. Generalização/especialização para construir uma hierarquia de generalização

Classificação/instanciação

• Classificar significa agrupar objetos com estruturas e comportamento semelhantes.

• Instanciar objetos significa gerar novos • Instanciar objetos significa gerar novos exemplares a partir de uma definição abstrata de um objeto genérico

Classificação/instanciação

Aluno-nome:String-ra:Int Classificação Instanciação

classe

-ra:Int+verificarRa(ra:Int):boolean

José:Aluno Maria:Aluno

Classificação Instanciação

<<instance_of>> <<instance_of>>(os objetos depen-dem da classe)

objeto objeto

Um objeto é instância de apenas uma classeUma classe pode possuir várias instâncias (objetos)

Classificação/instanciação

Quantas classes você vê? Quantos objetos?

Generalização/Especialização

• É um tipo de : Implementa o conceito de herança de tipos

• Permite que todas as instancias

de uma categoria específica

tenham também as

características decaracterísticas de

uma categoria

mais abrangente.

Generalização/Especialização

Usuario-nome:String-cod:Int+verificarCod(cod:Int):boolean

Generalização Especialização

classe base

+verificarCod(cod:Int):boolean

Classe derivada

Aluno-serie:int+suspender():void

Professor-tempoServ:int+aposentar():void

Classe derivada

Generalização/Especialização Objetos

josé:Usuario-nome=“José”:String-cod=“ra123”:Int+verificarCod(cod:Int):boolean

maria:Aluno-nome=“Maria”:String-cod=“ra235”:Int-serie=“2”:int+verificarCod(cod:Int):boolean+suspender():void

elaine:Professor-nome=“Elaine”:String-cod=“rf345”:Int-tempoServ:=“15”int +verificarCod(cod:Int):boolean+aposentar():void

Agregação/Decomposição

• Agregação é um relacionamento estrutural entre o todo e suas partes.

• É-parte-de: implementa o conceito de • É-parte-de: implementa o conceito de decomposição hierárquica

• É um mecanismo que permite a montagem do todo a partir de suas partes

Agregação/Decomposição

Biblioteca-identificador:String-endereço:String+listar usuarios():void+listar livros():void

Agregação Decomposição

Usuario-nome:String-cod:Int+verificarCod(cod:Int):boolean

+listar livros():void

Livro-tombo:int-nome:String+buscar():void

Associação

• É um relacionamento estrutural que descreve um conjunto de “links”;

• Agregação é um tipo especial de associação;

• Um usuário pode efetuar várias reservas e uma • Um usuário pode efetuar várias reservas e uma reserva é feita por apenas um usuário.

Usuario-nome:String-cod:Int+verificarCod(cod:Int):boolean

Reserva-codigo:int-data:Date+efetuar():void+cancelar():void

*1

Orientação a Objetos

• Programação Orientada a Objetos (POO) – é um modelo de programação baseado em

conceitos, tais como, objetos, classes, conceitos, tais como, objetos, classes, encapsulamento, herança, etc.

• Projeto Orientado a Objetos (“Object-Oriented Design”)

– é um modo de usar esses conceitos para estruturar e construir sistemas.

Metodologia Orientada a Objetos

• A abordagem orientada a objetos para construção de sistemas permite que um mesmo conjunto de conceitos e uma mesma mesmo conjunto de conceitos e uma mesma notação sejam usados através de todo o ciclo de vida do software: análise, projeto e implementação.

Unified Modeling Language (UML)

• É um modelo de linguagem.

• Se uma pessoa quer conversar com outra sobre o projeto é através do modelo de sobre o projeto é através do modelo de linguagem que elas se entendem.

• Não é um método, pois não possui um processo. É a notação que o método usa para descrever o projeto.

Unified Modeling Language (UML)

• Sua especificação iniciou-se em 1994 pela Rational Software Corporation

• Tornou-se padrão do Object Management • Tornou-se padrão do Object Management Group (OMG) em 1997

• Se popularizou após a criação do Rational Unified Process (RUP), em 1998

Alguns Diagramas UML

• Diagrama de Casos de Uso

• Diagrama de Classes

• Diagrama de Seqüência• Diagrama de Seqüência

• Diagrama de Colaboração

• Diagrama de Atividades

• Diagrama de Estado

• ...