Programando Sistemas

Prévia do material em texto

19
SISTEMA DE ENSINO PRESENCIAL CONECTADO
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
EMERSON ALMIRANTE BASTOS
DESENVOLVIMENTO DE SISTEMAS ii
Programando Sistemas
Paulista
2015
emerson almirante bastos
DESENVOLVIMENTO DE SISTEMAS ii
Programando Sistemas
Projeto do Curso Análise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, como requisito parcial para obtenção da média do terceiro semestre para as disciplinas Banco de Dados 2, Análise Orientada de Objetos 2, Programação Orientada a Objetos, e Programação Web.
Professor Luiz Claudio Perini, Roberto Yukio Nishimura, Mácio roberto Chiaveli, e Professora Veronice de Freitas.
Paulista
2015
SUMÁRIO
1	INTRODUÇÃO	3
1.1	OBJETIVO	3
2	Análise Orientada a Objetos II	4
3	Banco de Dados II	11
4	Programação Orientada a objetos	21
5	Programação web I	34
CONCLUSÃO	42
REFERÊNCIAS	43
INTRODUÇÃO
O conteúdo deste material tem finalidade de demonstrar a continuação do trabalho mostrado no semestre passado, com aplicações da Análise Orientada de Objetos II, Banco de Dados II, Programação Orientada a Objetos e Programação Web para desenvolver programas de utilização no dia-a-dia de empresas e usuários que necessitam de automação nos seus serviços.
O analista de sistemas deve garantir o alinhamento entre tecnologia e estratégias organizacionais, os projetos de software devem conhecer o cenário organizacional em um nível suficiente, a ponto de avaliar e sugerir melhorias, ou mesmo reengenharia nos processos de negócio. Este trabalho mostrará na prática a importância das técnicas e o desenvolvimento do sistema que iremos utilizar a linguagem C#, através do diagrama de atividades, bem como a modelagem de dados na utilização dos consagrados bancos de dados relacionais juntamente com a programação orientada a objetos, viabilizando o sucesso dos sistemas no que tange o alinhamento dos objetivos aos processos das organizações.
OBJETIVO
Buscando alcançar aprimoramento na elaboração de diagramas de sistemas e analises das criações de programas, elaborar estruturadamente bancos de dados , crescimento e aprofundamento no mercado da Tecnologia, trazendo para mim as melhorias alcançadas, desenvolvendo Programas os quais auxiliem e facilitem o dia a dia dos nossos usuários tendo em vista que; para aprimorar cada vez mais nosso meio de trabalho devemos obter grande conhecimento, sabendo que desta forma a responsabilidade aumenta tanto na postura de assumir como um Analista e Desenvolvedor, em busca de satisfazer não somente o cliente alvo e sim crescer neste mundo da Tecnologia. Por isso cabe ao profissional obter mais conhecimento, postura e conduta no seu meio de trabalho e assim aperfeiçoar seus conhecimentos naquilo que ele deseja aprofundar-se seja em quaisquer linguagens de programação e ou Sistemas Operacionais.
Análise Orientada a Objetos II 
Consiste da definição das classes (objetos) que representam o problema a ser resolvido, o modo pelo qual as classes se relacionam e interagem umas com as outras, o funcionamento interno (atributos e operações) dos objetos e os mecanismos de comunicação (mensagens) que permitem a eles trabalharem juntos. Deve-se fazer uma descrição das características estáticas e dinâmicas das classes que descrevem um sistema ou um produto.
A OOA fornece um modo concreto de representar seu entendimento dos requisitos e depois testar esse entendimento contra a percepção do cliente.
UML é um acrônimo para a expressão Unified Modeling Language. Pela definição de seu nome, vemos que UML é uma linguagem que define uma série de artefatos que nos ajuda na tarefa de modelar e documentar os sistemas orientados a objetos que desenvolvemos.
Ela possui nove tipos de diagramas que são usados para documentar e modelar diversos aspectos dos sistemas.
A maioria dos problemas encontrados em sistemas orientados a objetos tem sua origem na construção do modelo, no desenho do sistema. Muitas vezes as empresas e profissionais não dão muita ênfase à essa fase do projeto, e acabam cometendo diversos erros de análise e modelagem. Isso quando há modelagem, pois nós profissionais da área sabemos que muitas vezes o projeto começa já na fase de codificação.
A UML é muito mais que a padronização de uma notação. É também o desenvolvimento de novos conceitos não normalmente usados. Por isso e muitas outras razões, o bom entendimento da UML não é apenas aprender a simbologia e o seu significado, mas também significa aprender a modelar orientado a objetos no estado da arte.
 	Em UML, um sistema é representado usando cinco diferentes “visões”, a saber:
Visão do modelo do usuário: representa o sistema (produto) a partir da perspectiva do usuário (chamados de atores em UML). O caso de uso é a abordagem de modelagem escolhida para a visão do modelo do usuário;
Visão do modelo estrutural: Dados e funcionalidades são vistos de dentro do sistema. Isto é, a estrutura estática (classes, objetos e relacionamentos) é modelada;
Visão do modelo comportamental: Essa parte do modelo de análise representa os aspectos dinâmicos ou comportamentais do sistema. Ela também mostra as interações ou colaborações entre os vários elementos estruturais descritos nas visões do modelo do usuário e do modelo estrutural;
Visão do modelo de implementação: Os aspectos estruturais e comportamentais do sistema são representados da forma como devem ser construídos;
Visão do modelo do ambiente: Os aspectos estruturais e comportamentais do ambiente, no qual o sistema deverá ser implementado, devem ser representados.
A OOA pode ocorrer em muitos níveis de abstração diferentes. No nível de negócio ou de empresa, as técnicas associadas com a OOA podem ser combinadas com uma abordagem de engenharia de processos de negócio, num esforço para definir classes, objetos, relacionamentos e comportamentos que modelem todo o negócio. Em seu nível mais baixo de abstração, cai no âmbito da engenharia de software orientada a objetos.
Principais Diagramas
Diagrama de Casos de Uso
Destina-se a Equipe de Desenvolvimento, para dar uma visão do que o cliente quer. Esse diagrama documenta o que o sistema faz do ponto de vista do usuário. Em outras palavras, ele descreve as principais funcionalidades do sistema e a interação dessas funcionalidades com os usuários do mesmo sistema. Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz.
Este artefato é comumente derivado da especificação de requisitos, que por sua vez não faz parte da UML. Pode ser utilizado também para criar o documento de requisitos.
Diagramas de Casos de Uso são compostos basicamente por quatro partes:
Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.
Ator: Usuário do sistema, ou melhor, um tipo de usuário.
Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário)
Comunicação: é o que liga um ator com um caso de uso
Vamos criar um cenário de exemplo para vermos a notação de um diagrama de caso de uso no estudo proposto:
“Uma empresa Perfeita precisa de um sistema de Gerenciamento de frotas de veículos para agilizar o transporte de seus funcionários. Um funcionário entra em contato com o setor para solicitar um veículo. O atendente procura data e hora disponível mais próxima na agenda da reserva do veículo. Posteriormente o funcionário vai ao local marcado para utilizar o veículo, e devolve o mesmo no dia e hora marcada, para já ser agendado para utilização de outro funcionário”.
Com esse cenário simples podemos começar a criar nosso diagrama. Inicialmente vamos definir nossos atores:
a) Funcionário 
b) Atendente
Agora vamos definir algumas ações de cada usuário:
a) Funcionário
· Solicita o Veículo
· Solicita Cancelamento do Veículo
 
b) Atendente
· Consulta Reservas· Marca Reserva
· Cancela Reserva
Bom, agora já temos uma relação de atores e ações relacionadas a esses atores. Poderíamos criar um documento textual (como foi feito acima), para registrar nossos atores e funcionalidades. Mas expressarei uma imagem e definirei tudo em um desenho simples utilizando os padrões da UML para documentação de casos de uso.
No quadro abaixo segue a definição de algumas figuras do diagrama:
Fonte do autor:
; cada mudança constitui um novo estado.
Diagrama de Classes
Um diagrama de classes é um modelo fundamental de uma especificação orientada a objetos. Produz a descrição mais próxima da estrutura do código de um programa, ou seja, mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes. Classes e relacionamentos constituem os elementos sintáticos básicos do diagrama de classes (SILVA, 2007).
Diagrama de Objetos
O diagrama de objetos consiste em uma variação do diagrama de classes em que, em vez de classes, são representadas instâncias e ligações entre instâncias. A finalidade é descrever um conjunto de objetos e seus relacionamentos em um ponto no tempo.
Contém objetos e vínculos e são usados para fazer a modelagem da visão de projeto estática de um sistema a partir da perspectiva de instâncias reais ou prototípicas.
Diagrama de Pacotes
O pacote é um elemento sintático voltado a conter elementos sintáticos de uma especificação orientada a objetos. Esse elemento foi definido na primeira versão de UML para ser usado nos diagramas então existentes, como diagrama de classes, por exemplo. Na segunda versão da linguagem, foi introduzido um novo diagrama, o diagrama de pacotes, voltado a conter exclusivamente pacotes e relacionamentos entre pacotes (SILVA, 2007). Sua finalidade é tratar a modelagem estrutural do sistema dividindo o modelo em divisões lógicas e descrevendo as interações entre ele em alto nível.
Diagrama de Estrutura Composta
O diagrama de estrutura composta fornece meios de definir a estrutura de um elemento e de focalizá-la no detalhe, na construção e em relacionamentos internos. É um dos novos diagramas propostos na segunda versão de UML, voltado a detalhar elementos de modelagem estrutural, como classes, pacotes e componentes, descrevendo sua estrutura interna.
O diagrama de estrutura composta introduz a noção de “porto”, um ponto de conexão do elemento modelado, a quem podem ser associadas interfaces. Também utiliza a noção de “colaboração”, que consiste em um conjunto de elementos interligados através de seus portos para a execução de uma funcionalidade específica recurso útil para a modelagem de padrões de projeto (SILVA, 2007).
Diagrama de Componentes
O diagrama de componentes é um dos dois diagramas de UML voltados a modelar software baseado em componentes. Tem por finalidade indicar os componentes do software e seus relacionamentos. Este diagrama mostra os artefatos de que os componentes são feitos, como arquivos de código fonte, bibliotecas de programação ou tabelas de bancos de dados. As interfaces é que possibilitam as associações entre os componentes.
Diagrama de Implantação
O diagrama de utilização, também denominado diagrama de implantação, consiste na organização do conjunto de elementos de um sistema para a sua execução. O principal elemento deste diagrama é o nodo, que representa um recurso computacional. Podem ser representados em um diagrama tantos os nodos como instâncias de nodos.
O diagrama de implantação é útil em projetos onde há muita interdependência entre pedaços de hardware e software.
Diagrama de Sequência
O diagrama de sequência mostra a troca de mensagens entre diversos objetos, em uma situação específica e delimitada no tempo. Coloca ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas.
Em diagramas de sequência, objetos são representados através de linhas verticais tracejadas (denominadas como linha de existência), com o nome do objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um objeto para outro na forma de setas com a operação e os nomes dos parâmetros.
Diagrama de Máquina de Estados
O diagrama de máquina de estados tem como elementos principais o estado, que modela uma situação em que o elemento modelado pode estar ao longo de sua existência, e a transição, que leva o elemento modelado de um estado para o outro. O diagrama de máquina de estados vê os objetos como máquinas de estados ou autômatos finitos que poderão estar em um estado pertencente a uma lista de estados finita e que poderão mudar o seu estado através de um estímulo pertencente a um conjunto finito de estímulos.
Diagrama de Comunicação
Os elementos de um sistema trabalham em conjunto para cumprir os objetos do sistema e uma linguagem de modelagem precisa poder representar esta característica. O diagrama de comunicação é voltado a descrever objetos interagindo e seus principais elementos sintáticos são “objeto” e “mensagem”. Corresponde a um formato alternativo para descrever interação entre objetos. Ao contrário do diagrama de sequência, o tempo não é modelado explicitamente, uma vez que a ordem das mensagens é definida através de enumeração. Vale ressaltar que tanto o diagrama de comunicação como o diagrama de sequência são diagramas de interação.
 Diagrama de Atividades
O diagrama de atividades representa a execução das ações e as transições que são acionadas pela conclusão de outras ações ou atividades.
Uma atividade pode ser descrita como um conjunto de ações e um conjunto de atividades. A diferença básica entre os dois conceitos que descrevem comportamento é que a ação é atômica, admitindo particionamento, o que não se aplica a atividade, que pode ser detalhada em atividades e ações (SILVA, 2007).
Diagrama de Visão Geral de Integração
O diagrama de visão geral de interação é uma variação do diagrama de atividades, proposto na versão atual de UML. Seus elementos sintáticos são os mesmos do diagrama de atividades. As interações que fazem parte do diagrama de visão geral de interação podem ser referências a diagramas de interação existentes na especificação tratada.
Diagrama de Temporização
O diagrama de temporização consiste na modelagem de restrições temporais do sistema. É um diagrama introduzido na segunda versão de UML, classificado como diagrama de interação. Este diagrama modela interação e evolução de estados.
banco de Dados II
O Modelo Entidade-Relacionamento (MER) é um modelo de dados de alto-nível criado com o objetivo de representar a semântica associada aos dados do minimundo. O MER é utilizado para na fase de projeto conceitual, onde o esquema conceitual do banco de dados da aplicação é concebido. 
Seus conceitos são intuitivos, permitindo que projetistas de banco de dado capturem os conceitos associados aos dados da aplicação, sem a interferência da tecnologia específica de implementação do banco de dados.
O esquema conceitual criado usando-se o MER é chamado Diagrama Entidade-Relacionamento(DER).
MER: Conjunto de conceitos e elementos de modelagem que o projetista de banco de dados precisa conhecer DER: Resultado do processo de modelagem executado pelo projetista de dados que conhece o MER.
Entidades e Atributos
O objeto mais elementar que o MER representa é a entidade. Uma entidade é algo do mundo real que possui uma existência independente. Objetos, pessoas, empregado, entes, conceitos, "coisas", etc. - do mundo real são representados como Entidades. Cada Entidade tem propriedades particulares que são chamadas de 
Atributos.
Exemplo de uma Entidade Empregado
Uma entidade EMPREGADO pode ser descrita pelo seu nome, o trabalho que realiza, idade, endereço e salário. 
Uma entidade em particular terá um valor para cada um de seus atributos.
Atributos Compostos
Alguns atributos podem ser divididos em subpartes com significados independentes.Atributos Multivalorados
Muitos atributos têm apenas um valor (uni-valorados). Porém existem atributos que podem ter um conjunto de valores (Multivalorados).
Atributos Derivados
São atributos cujos valores devem ser obtidos após algum processamento utilizando informações obtidas do próprio 
banco de dados:
Idade = Data_Atual - Data_Nascimento
Número de empregados de um determinado departamento
Valores Nulos de Atributos
Algumas vezes pode acontecer de um atributo não possuir valor. Nesses casos, atribui-se um valor nulo (null) para esse atributo.
Apartamento = null
para aqueles empregados que não residam em um prédio. (Não aplicável)
O valor null pode ser aplicado também para denotar que o valor é
desconhecido. 
Tipos de Entidades
Entidades que têm a mesma "estrutura" e a mesma semântica, são representadas como Tipo de Entidade. 
Atributo-Chave
Uma restrição importante sobre entidades de um tipo de entidade é a restrição de atributo-chave.
Todo Tipo de Entidade deve ter um atributo-chave, seja ele um atributo simples ou composto.
Os valores de um atributo-chave devem ser distintos. Esta unicidade deve valer para quaisquer extensões desse tipo de entidade. Relacionamentos e Tipos de Relacionamentos
Um relacionamento é uma associação entre uma ou mais entidades
.
Grau de um Tipo de Relacionamento
O Grau de um Tipo de Relacionamento = número de Tipos de Entidades Envolvidas
Relacionamento como Atributo
‡
O Tipo de Relacionamento 
EMPREGADO TRABALHA_PARA DEPARTAMENTO 
pode ser pensado como:
EMPREGADOpossuindo um atributo DEPARTAMENTO ou
DEPARTAMENTO possuindo um atributo EMPREGADO
(multivalorado)
Papéis e Relacionamentos Recursivos 
Cada tipo de entidade que participa de um tipo de relacionamento possui um papelespecífico. 
No caso de: 
EMPREGADO TRABALHA_PARA DEPARTAMENTO, o papel de EMPREGADO é empregado ou trabalhador e do 
DEPARTAMENTO é empregador. 
A escolha do nome nem sempre é simples. 
Papéis e Relacionamentos Recursivos
‡
Existem casos em que a indicação do papel é necessária.
Em tipos de Relacionamentos Recursivos
Papéis e Relacionamentos Recursivos
Em Tipos de Relacionamentos cuja semântica não fique clara ou seja ambígua:
EMPRESA CONTRATA DEPARTAMENTO
EMPRESA INVESTE PESSOA
DEPARTAMENTO GERENCIA PESSOA 
Restrições sobre Tipos de Relacionamentos
Razão de Cardinalidade: especifica a quantidade de instâncias de 
relacionamentos em que uma entidade pode participar (1:1, 1:N, N:N)
Participação: especifica se a existência de uma entidade depende dela estar relacionada com outra entidade através de um relacionamento.
Total (Dependência existencial)
Parcial
Razão de Cardinalidade
EMPREGADO TRABALHA_PARA DEPARTAMENT: (1:N)
Razão de Cardinalidade
‡
EMPREGADO GERENCIA DEPARTAMENTO: (1:1)
Razão de Cardinalidade
‡
EMPREGADO TRABALHA_EM PROJETO: (N:N)
Restrição de Participação
EMPREGADO TRABALHA_PARA DEPARTAMENTO
Empregado somente pode existir se estiver relacionado com algum departamento (Participação Total)
Departamento pode existir mesmo não tendo nenhum empregado (Participação Parcial)
Restrição Estrutural A restrição estrutural de:
EMPREGADO é (1,1), pois participa em No mínimo em 1 e no máximo em 1 relacionamento DEPARTAMENTO é (0, N), pois participa em No mínimo 0 e no máximo N relacionamentos
Atributo de Relacionamento
Os Tipos de Relacionamentos também podem ter Atributos. Por exemplo:
Quantidade de horas trabalhadas por um empregado em um dado projeto (Horas)
Pode ser representado como um atributo do relacionamento TRABALHA_EM Data em que um gerente começou a gerenciar um departamento (DataInício)
Pode ser representado como um atributo do relacionamento GERENCIA
Atributo de Relacionamento
Atributos de Tipos de Relacionamentos 1:1 podem ser colocados em um dos Tipos de Entidades participantes
DataInício em EMPREGADO GERENCIA DEPARTAMENTO
Atributo de Relacionamento
Atributos de TR 1:N podem ser colocados no TE que está no lado N do relacionamento
DataInício em EMPREGADO TRABALHA_PARA DEPARTAMENTO
Tipo de Entidade-Fraca
São Tipos de Entidades que não têm atributos-chaves. Entidades só podem ser identificadas através da associação com uma outra Entidade.
Tipo de Entidade-Fraca
Um tipo de entidade-fraca sempre tem restrição de participação total(dependência existencial) com respeito ao seu tipo de relacionamento de identificação, porque não é possível identificar 
uma entidade-fraca sem a correspondente entidade proprietária. 
‡
Um tipo de entidade-fraca tem uma chave-parcial, que é um conjunto de atributos que pode univocamente identificar entidades-fracas relacionadas à mesma entidade proprietária. 
Notação do DER
O DER do Sistema Companhia
Programação Orientada a objetos
Com o desenvolvimento de aplicações de software Com o desenvolvimento de aplicações de software cada vez mais complexas, cresceram as demandas cada vez mais complexas, cresceram as demandas por metodologias que pudessem abstrair e por metodologias que pudessem abstrair e modularizar as estruturas básicas de programas. 
Modularizar as estruturas básicas de programas.
	A programação OO suporta a abstração e A programação OO suporta a abstração e modularização através da especificação de tipos modularização através da especificação de tipos abstratos de dados (as classe), e promove a abstratos de dados (as classe), e promove a reutilização de software por meio do mecanismos de reutilização de software por meio do mecanismos de herança.
	
	A programação OO busca modelar aplicações A programação OO busca modelar aplicações seguindo uma estrutura semelhante àquela seguindo uma estrutura semelhante àquela encontrada no mundo real. 
O mundo é composto por objetos que apresentam O mundo é composto por objetos que apresentam estados e comportamentos. 
Estados e comportamentos.
Um gato por exemplo tem um nome, uma cor e uma Um gato por exemplo tem um nome, uma cor e uma raça (os estados) e ele come, mia e caça ratos (os raça (os estados) e ele come, mia e caça ratos (os comportamentos).
Modelo OO
Uma aplicação OO é composta por diferentes objetos e uma sequência de ações (interações). Uma ação se inicia através do envio de uma mensagem para um agente (um objeto) que será responsável por tratar essa ação. 
A mensagem carrega uma requisição, além de toda a informação necessária (argumentos) para que a ação seja executada. Se o agente receptor da mensagem a aceita, ele tem a responsabilidade de executar um método para cumprir a requisição. 
Objetos
Constituem as estruturas básicas de uma aplicação. Estão preparados para cumprir um determinado conjunto de requisições. Recebem essas requisições através de mensagens. Possuem a responsabilidade de executar um método que cumpra a requisição. Possuem um estado representado por informações representado por informações internas. 
Atributos, Métodos e Mensagens 
Um objeto é composto por atributos e métodos. Um objeto é composto por atributos e métodos. O estado de um objeto é representado por variáveis denominadas atributos. Alterações no estado de um objeto geralmente ocorrem através da invocação de seus métodos. Métodos são as rotinas que descrevem os possíveis comportamentos ou ações de um objeto. Um método de um objeto é invocado do através do envio, ao objeto, de uma mensagem apropriada.
Interface (Protocolo)
Parte privada do objeto (visão interna) Métodos usados internamente e atributos. Parte compartilhada do objeto (interface ou Parte compartilhada do objeto protocolo). Métodos que podem ser invocados externamente. Corresponde às mensagens que um objeto é capaz de responder. Especifica portanto um contrato quais as operações que o objeto pode e deve realizar.
Não contém qualquer informação sobre como as operações devem ser executadas ou implementadas
Encapsulamento
Princípioaplicado a programação OO visando garantir a abstração dos dados (esconde os detalhes da implementação).
Um objeto não deve permitir que nenhum outro objeto acesse seus dados diretamente.
O relacionamento entre objetos deve ocorrer preferencialmente a partir de métodos públicos (interface). Caso haja uma mudança na implementação da classe, o relacionamento entre os objetos não será afetado.
Classes
Especificam que informações um objeto irá armazenar (os atributos), e o conjunto de requisições que um objeto pode cumprir (os métodos). Encapsulam a implementação dos métodos. Encapsulam a implementação dos métodos. Definem a interface de um objeto. 
Objetos são instâncias de classes. Classes podem ser compostas em hierarquias, através de através de herança.
Herança
Permite a definição de classes específicas (subclasses) a partir de classes gerais. 
Superclasses
Subclasses herdam todos os atributos e métodos da superclasse. Subclasses podem declarar novos métodos e atributos ou mesmo redeclarar métodos definidos pela superclasse (sobreescrever overriding).
Exemplo – C++
class Poligono {
protected:
int altura, largura; 
public:
void set_valor (int a, int b)
{ largura=a; altura=b;}
};
class Retangulo: public Poligono {
public:
int area (void) 
{ return (altura * largura); }
};
int main () {
Retangulo ret; ----- um objeto
ret.set_valor(4,3); ------------- uma mensagem
Herança 
Quando uma classe B herda de herda de A, diz-se que B é uma subclasse de A, e A é a superclasse de B.
No exemplo anterior Retângulo é uma subclasse de Polígono, e Polígono é a superclasse de Retângulo. 
Uma subclasse especializa uma superclasse quando redefine métodos, sem ampliar sua interface. 
Uma subclasse estende uma superclasse quando amplia a sua interface, declarando novos métodos, mas sem redefinir os interface os métodos herdados. Uma subclasse pode ao mesmo tempo estender e especializar uma superclasse.
Herança de Interface
Em algumas LPs é possível distinguir entre herança de implementação e herança de interface. Na herança de interface uma classe herda uma ou mais interfaces. As interfaces estabelecem os métodos (e as respectivas assinaturas) que devem ser implementados pela classe, mas a implementação deve ser integralmente especificada pela subclasse. A herança de implementação usualmente implica na herança de interface.
Exemplo – Java
public interface Relogio {
Date getData();
Time getHora();
void setData(Date d);
void setHora(Time t);
}
public Class RelogioDigital implements Relogio{
Date getData(){ ... }
Time getHora(){ ... }
void setData(Date d){ ... }
void setHora(Time t){ ... }
void setAlarme(int size){ ... }
void Display(){ ... }
...
}
Herança de Interface
A herança de interface é utilizada quando é preciso garantir que uma determinada classe seja capaz de tratar um conjunto particular de mensagens.
A implementação das mensagens é específica de cada classe, e não faz sentido a reutilização de código.
Um exemplo comum é a interface Runnable:
interface Runnable {
void run();
}
Herança Múltipla
Em algumas situações pode ser interessante definir uma classe a partir de propriedades de duas ou mais classes distintas.
Algumas LPs (C++, Eiffel, Smalltalk) suportam este tipo de estrutura através do mecanismo de herança múltipla.
Exemplo – C++
class square{int side;
public:
int area(){return side * side;}
};
class color{
char *color_name;
public:
char *get_color(){return color_name;}
};
class colored_square: public color, public square{
};
int main () {
colored_square s;
...
x = s.get_color();
y = s.area();
}
Anomalia de Herança
O mecanismo de herança múltipla introduz um problema conhecido como anomalia de herança. O que acontece com a subclasse se duas superclasses contém métodos com a mesma assinatura?
Relacionamentos
Uma aplicação OO é estruturada através da especificação de classes e objetos, e dos relacionamentos entre estes.
A relação de herança por exemplo é usada para obter o efeito de especialização entre classes. Caminhão é uma especialização de veículo. A relação inversa de especialização é a generalização (veículo é uma generalização de caminhão).
Outros exemplos de relacionamento entre classes são:
Composição ou agregação;
Associação;
Uso.
Composição
Neste caso podemos definir uma classe como sendo composta por objetos de outras classes. Não é necessário nenhuma construção especial para suportar composições, basta declarar as classes componentes como atributos da classe composta.
Associação
Ocorre quando um objeto faz referência a um objeto de outra classe.
No exemplo abaixo, um Motorista está associado a um Veículo.
Polimorfismo 
é a capacidade de um objeto tomar diversas formas.
Coerção e Sobrecarga
Em LPs com coerção um tipo pode ser transformado em outro dependendo do contexto:
int x =5;
float y = 3.5*x;
No caso de sobrecarga, um mesmo nome denota funções diferentes também conforme o contexto:
String s = “João” + “Silva”;
int x = 4 + 5;
Polimorfismo Paramétrico
O comportamento de uma estrutura qualquer depende de uma parâmetro que indica o tipo de dado a ser tratado:
Class stack [T]
variable lst : List[T] := new List[T]
method push(x:T) returns nothing
lst := lst.prepend(x)
method pop() returns T
variable tmp : T := lst.head()
lst := lst.tail()
return tmp
method top() returns T
return lst.head()
method empty?() returns Boolean
returns lst.empty?()
Polimorfismo de Subtipo
Este é o polimorfismo mais comum em LPs OO, e é o tipo ao qual geralmente nos referimos quando utilizamos o termo polimorfismo. Quando declaramos uma variável como sendo de uma classe específica, ela pode conter instâncias de quaisquer subclasses desta classe específica. Como a interpretação de uma mensagem é da responsabilidade do objeto que a recebe, uma mesma mensagem pode ser interpretada de forma diferente dependendo do objeto que a recebe. A definição do método que irá ser executado como resultado do envio de uma mensagem geralmente só acontece em tempo de execução (late-binding).
Exemplo
Animal a;
a = new Cachorro();
a.falar(); -> au! au!
a = new Gato();
a.falar(); -> miau! miau!
a = new Galinha();
a.falar(); -> cocorocó!
Typecast
Para acessar um método específico de uma subclasse é necessário fazer um typecast da variável declarada como da superclasse. 
Exemplo:
Animal a;
a = new Galinha();
((Galinha)a).botar_ovo;
a = new Cachorro();
((Galinha)a).botar_ovo; -> erro
Métodos Virtuais ou Abstratos
Quando apenas a assinatura de um método é declarada por uma classe este método é denominado virtual ou abstrato. Classes abstratas devem ter pelo menos um método virtual. Em C++ apenas os métodos declarados como virtuais são vinculados dinamicamente (latebinding). Em Java todos os métodos são vinculados dinamicamente.
Late Binding em C++
Para implementar o late binding de métodos, o compilador C++ cria uma tabela denominada VTABLE para todas as classes que contém métodos virtuais.
A VTABLE armazena o endereço dos métodos virtuais. Adicionalmente, para todas as classes com métodos virtuais é criado um atributo denominado vpointer (VPTR) que aponta para a VTABLE do objeto. Quando um método é invocado, a VTABLE do objeto é utilizada para descobrir o endereço do método específico que deve ser executado.
Construtores e Destrutores
A instanciação de um objeto usualmente acontece através da invocação de um método especial conhecido como construtor. O construtor é responsável por inicializar adequadamente o objeto. Algumas LPs OO suportam também o conceito de destrutores, métodos que são executados antes de um objeto ser destruído (deslocado da memória).
Exemplo
class Date {
private:
int day;
int month;
int year;
public:
// Construtor
Date(int d, int m, int y) {
set(d, m, y);
}
// Destrutor
~Date(){
...
}
void set(int d, int m, int y);
...
};
Sobrecarga em LPs OO
Em programaçãoOO é bastante comum a definição de métodos sobrecarregados. Um exemplo de aplicação é na definição de construtores. O método associado a uma invocação pode ser determinado a partir da análise léxica (estática) do código (desde que não haja a possibilidade de polimorfismo).
Exemplo
class Date {
private:
int day, month, year;
public:
// Construtor 1
Date(int d, int m, int y) {
set(d, m, y);
}
// Construtor 2
Date() {
set(1, 1, 2000);
}
...
};
int main () {
Date d(); // Construtor 1
...
}
Atributos de Classes e Métodos Estáticos
Em algumas LPs OO pode-se definir atributos associados diretamente a uma classe. Os atributos de uma classe podem ser manipulados apenas por métodos estáticos 􀃎􀃎métodos que também são associados a uma classe. Atributos de classe são equivalentes a variáveis globais de LPs não OO, e métodos estáticos equivalem a funções ordinárias.
Exemplos
public class Math{
private static double pi = 3.14;
public static double getPI(){
return pi;
}
}
public class Teste{
private static int instances = 0;
public Test(){
++instances;
}
...
}
programação web I
As aplicações web são aplicações de software que utilizam o browser como ambiente de execução, estas que são geralmente multiplataforma tem a vantagem de poder ser executada em qualquer máquina com acesso à internet, bastando apenas que a máquina possua os pré-requisitos desejados pela aplicação. Algumas aplicações até permitem que os arquivos dos usuários fiquem salvos na “nuvem”, sem que o usuário necessite armazená-lo em nenhum meio físico. 
Para a seleção das plataformas, inicialmente foram recolhidos as principais necessidades e requisitos para o desenvolvimento web. 
Os pré-requisitos estabelecidos para os tecnologias são:
Reproduzir som
Capturar teclas do teclado e posição do Mouse
Controle de Animações
Rodar processos paralelos (Threads)
Conexão com um ou mais servidores externo
Rodar nos principais browser
Rodar nos principais sistemas Operacionais
Possuir uma API de renderização 2D
As plataformas devem ser capaz de realizar os pré-requisitos sem a necessidade de integração com uma tecnologia externa, desta forma será mais fácil realizar as comparações visto que as possibilidades de integração principalmente com as tecnologias web são praticamente infinitas. 
Segundo a Net Applications (Empresa que analisa e estuda as características das plataformas que acessam a internet, gerando estatísticas do uso das plataformas), o Windows XP, Vista e o MAC OS X 10.5 juntos corresponde a cerca de 92.27% dos sistemas operacionais conectados a internet, e o Internet Explorer, o Firefox e o Safari juntos correspondem a 97.1% dos browser utilizados mundialmente. Com base nesses dados foi definido como pré-requisitos das plataformas selecionadas, rodar o lado cliente.
Java
A seguir será apresentado inicialmente como surgiu a plataforma Java e qual é o seu foco, mostrando em seguida uma análise dos recursos que a plataforma prover para o desenvolvedor. Para se executar um software desenvolvido em Java necessitam-se de dois componentes, o máquina virtual, e um conjunto de bibliotecas que disponibiliza uma série de serviços para o programa. 
A linguagem utilizada pela plataforma Java é uma linguagem de programação que recebe o mesmo nome da tecnologia. Esta foi criada para ser utilizada na plataforma Java, sendo compilada em bytecodes pelo desenvolvedor para finalmente ser interpretada pela JVM em tempo de execução na máquina do cliente. Existem atualmente diversas maneiras de desenvolver em Java, podendo integrar várias linguagens ao projeto, como próprio Java, orientada a objetos e fortemente tipada, e as linguagens interpretadas como o Groovy, o Ruby e o Jython, que são linguagens de script, com tipos dinâmicos e que são transformadas em bytecodes em tempo real, reduzindo performance do software mas permitindo um desenvolvimento rápido com tipos dinâmicos.
Para desenvolver em Java é necessário um kit chamado Java Development Kit (JDK) que é disponibilizado pela Sun. Este kit contém o Compilador Java e um importante conjunto de bibliotecas e ferramentas para o desenvolvimento, além de ser acompanhado pelo Java Runtime Environment (JRE). O kit é livre e open source e pode ser baixado no site da Sun.
Java na Web
Atualmente existem duas maneiras de disponibilizar uma aplicação Java na Web, a primeira e a mais antiga é utilizando a tecnologia Applet e a segunda é utilizando a WebStart, descreveremos as características de cada uma a seguir.
Java Applet
Primeiramente vamos explicar o que é applet. Apple é um componente de software que roda dentro de um contexto de outro programa, por exemplo, quando você está navegando no site do youtube, o vídeo que está sendo apresentado é renderizado por uma tecnologia independente do browser, e o restante do site é renderizado pelo browser em si, ou seja, é uma aplicação independente que complementa a aplicação principal.
O Java Applet foi a primeira tecnologia Java a sair do ambiente de execução do desktop e ir para a web. Foi introduzida na versão da linguagem Java em 1995 com o objetivo de prover mais interatividade a uma página web, complementado as limitações do HTML. Um applet Java pode ser executado dentro de um browser que der suporte a JVM ou por um AppletViewer – uma aplicação independente do browser para testar um applet.
Graças a independência da plataforma dos bytecodes do Java, os Java applets podem ser executados em diversas plataformas, como o Windows, Unix, Mac e o Linux.
Web Start
O Java Web Start surgiu em 2001, diferente dos Java applets, esta tecnologia permite que o usuário execute um programa online sem a necessidade do browser, utilizando uma janela do sistema operacional como se fosse um aplicação nativa, esta forma de executar tem uma enorme vantagem em comparação com os applets, pois alguns problemas de compatibilidade do Java com o browser como é encontrado com os applets simplesmente não existe. Além da tecnologia web star possuir uma configuração de sandbox com menos restrições, permitindo aplicações mais complexas. Sua desvantagem é que o web start não consegue se comunicar com o browser tão facilmente como é feito com os applets.
Silverlight
Apresento como surgiu a mais nova plataforma da Microsoft para o desenvolvimento de aplicações web, apresentando posteriormente os requisitos para a sua execução, as linguagens de programação suportadas e por fim as ferramentas existentes para o desenvolvimento na plataforma.
Para funcionar o silverlight necessita de um plug-in instalado no lado cliente, bastando que o cliente possua a versão mais nova do plug-in instalada para que todas as aplicações desenvolvidas com a tecnologia silverlight funcione, visto que a Microsoft garante a retro compatibilidade de sua plataforma.
O silverlight ganhou mais relevância com o lançamento de sua versão 2.0. Esta adicionou comandos mais completos para os seus componentes e grande performance com a compilação do silverlight para um código intermediário, compilando as linguagens da plataforma .Net, além do Java script, permitindo a interpretação do código intermediário para a linguagem de máquina mais rapidamente. Foi adicionado também um melhor suporte para a rede, incluindo a capacidade de se comunicar via socket.
Flash
A tecnologia flash está presente em cerca de 99% dos computadores conectados à internet segundo uma pesquisa realizada pela Adobe em 97. Estando na frente de tecnologias bem mais antigas como o Java por exemplo, a seguir apresentaremos como surgiu esta tecnologia, como é o desenvolvimento nesta plataforma e qual o futuro que a Abobe está direcionando esta tecnologia dominante nos browsers.
Estudo Comparativo
A análise a seguir foi realizada com os dados disponibilizados nos sites dos desenvolvedores de cada tecnologia. Apresentando apenas se a tecnologia dão suporte ou não à característica analisada.
Plataforma Java: O Java é uma linguagem orientada a objetos e possui umconceito de empacotamento de API´s em arquivos JAR, este método melhora bastante o reuso de código. Possuindo uma enorme capacidade de expansão.
Plataforma Silverlight: O Silverlight trabalha com as linguagens do pacote .NET, dentre as linguagens existes temos a linguagem C# que é a mais padronizada, com orientação a objetos e fortemente tipada, além de possuir uma excelente capacidade de reuso de código. A plataforma .NET permite o empacotamento de suas API´s externas em DLL´s, permitindo um reuso ainda maior de seu código.
Plataforma Flash: Em sua versão atual do seu script o ActionScript 3.0 possui também um excelente suporte a orientação a objetos. Além de possuir também um formato de empacotamento de suas classes para a criação de API´s externas. As classes são armazenadas em um formato chamado SWC, esta podem conter tanto as classes de códigos como podem conter conteúdo como imagens por exemplo.
Curva de Aprendizado
Plataforma Java: O Java possui uma curva de aprendizado relativamente grande, parte disso vem do fato do Java possuir uma orientação a objetos muito complexa e fragmentada, com muitas classes e heranças dificultando o aprendizado. Por exemplo, não é trivial implementar uma simples leitura de um arquivo de texto em Java, é necessário a utilização de várias classes intermediárias para realizar tal feito, além de possuir uma API complexa para o tratamento de interface gráfica, com a necessidade de importar várias classes para desenvolver tarefas simples.
Plataforma Silverlight: O Silverlight possui um script de fácil entendimento, e possui excelentes referencias online. Porem existem pequenas complicações como por exemplo, para poder acessar os eventos do teclado é necessário que o código possua acesso ao elemento gráfico raiz por exemplo, dificultando um pouco a criação de códigos simples.
Plataforma Flash: Dentre todas as plataformas apresentadas o Flash é a que possui a curva de aprendizado menor, permitindo que em poucas horas com a ferramenta, o desenvolvedor já consiga manipular eventos de tecla, acesso gráfico e manipulação de som, com um script poderoso é possível realizar complexas animações com filtro escrevendo poucas linhas de código, para realizar o mesmo feito em Java seria necessário utilizar APIs externas complicadíssimas e escrever muitas linhas de códigos. Uma das grandes complicações do flash é o seu poder de trabalhar com vários eventos assíncronos, em parte essa característica é muito boa para o desenvolvedor, podendo realizar tarefas enquanto aguarda a finalização de outras, o problema é que dependendo da quantidade de eventos simultâneos pode ficar complicado para o desenvolvedor consegui administrar todas as possibilidades de ocorrência dos eventos.
Interação com outras ferramentas
Plataforma Java: Por ser Open Source o Java já possui integração com diversos formatos de arquivos, permitindo que seja carregado por exemplo uma infinidade de formatos de imagens, áudio e vídeos com seus codecs específicos. O problema do Java é que essas bibliotecas estão espalhadas pela web, descentralizadas e muitas vezes não compatíveis entre si, dificultando para o desenvolvedor encontrar as bibliotecas para carregar um formato de arquivo que seja muito específico.
Plataforma Silverlight: O silverlight possui apenas um suporte completo para JPEG e PNG, possuindo também suporte limitado para outros formatos. Deixando a integração com ferramentas gráficas muito limitadas. • Plataforma Flash: O flash consegue importar praticamente todos os formatos de imagens disponíveis, alem de possuir uma excelente integração com outras plataformas da Adobe como as ferramentas gráficas Photoshop e Fireworks por exemplo. Essa integração das ferramentas facilitam na hora de portar os gráficos desenhados no Fireworks por exemplo para serem utilizados em um Jogo, deixando o flash na posição da ferramenta que possui a melhor integração com outras ferramentas gráficas para o desenvolvimento web.
Testes
Plataforma Java: As ferramentas de desenvolvimento mais utilizadas no mercado na plataforma Java possuem recursos de Testes e Debuggers excelentes, são elas o Eclipse e o Netbeans. Ambos com suporte a JUnit e com Debuggers embutido, realizar testes nesses frameworks é bem fácil e eficiente.
Plataforma Silverlight: Para o desenvolvimento de códigos complexos a Microsoft aconselha a utilizar a IDE Visual Studio, esta possui uma das melhores ferramentas de Debugger do mercado, com um complexo sistema de edição de variáveis em tempo de execução deixando a etapa de testes bem simples para o desenvolvedor.
Plataforma Flash: A ferramenta mais robusta recomendada pela Adobe para o desenvolvimento na plataforma Flash é o Flex Builder, este baseado na IDE Eclipse possui a mesma ferramenta de Debugger disponibilizada para o desenvolvimento na plataforma Java, com suporte a JUnit o Flash também possui excelentes recursos para teste.
Disponibilização do Produto
Plataforma Java: Para se disponibilizar um software Java utilizando a APIgráfica Applet é bem simples, bastando comprimir os binários do projeto para o formato .jar criar uma tag no HTML dizendo que o conteúdo é um Applet para que o Browser passe o processo para a máquina virtual Java.
Uma vantagem desse processo é que os binários necessários ficam todos armazenados em um só arquivo, dependendo da implementação podendo conter dependência externa ou não. Um Applet Java pode ser executado localmente na máquina do usuários, sem a necessidade do browser, bastando ter o um player de Applet Java instalado.
Plataforma Silverlight: O Silverlight trabalha cada componente de forma separada, necessitando que cada componente seja disponibilizando separadamente. Logo é necessário colocar no servidor todos os conjuntos de classes e recursos da aplicação, necessitando que ao portar a aplicação de um lugar para outro seja necessário carregar todo o conjunto de dependências junto. Outra desvantagem do Silverlight é que não é possível executar um projeto desenvolvido nesta tecnologia localmente na máquina, sendo necessário sempre o browser para executar a aplicação. Uma vantagem neste modo de disponibilizar o conteúdo é que com os recursos do projeto ficam disponíveis para acesso, é possível indexar as imagens e os textos das aplicações Silverlight, diferentemente das aplicações Flash e Java que o conteúdo fica comprimido.
Plataforma Flash: Semelhante ao Java, o Flash também comprime todos os códigos compilados e recursos como as imagens e animações em um único arquivo no formato .swf. Para carregar este arquivo basta adicionar uma tag HTML dizendo para o brower que existe uma aplicação flash, e passa o controle para o Flash Player. Outra vantagem do flash é a possibilidade de executar um arquivo swf localmente na máquina do usuário, sem a necessidade do browser. Sendo muito fácil disponibilizar e distribuir uma aplicação flash.
Estudo Comparativo
Dentre todas as plataformas apresentadas acima foram selecionadas duas delas, onde foi desenvolvido o mesmo jogo nas duas plataformas com a finalidade de comparar a complexidade de seu desenvolvimento em cada uma das tecnologias.
As plataformas selecionadas foram o flash por estar presente em 98% dos computadores conectados à internet e ser praticamente a tecnologia dominante para o desenvolvimento de jogos casuais na internet e o Silverlight por ser uma recente alternativa ao flash, que vem ampliando o seu mercado em ritmo acelerado e recebendo atualizações de novos recursos com uma frequência maior que a sua concorrente, além de possuírem características semelhantes, possibilitando assim um estudo comparativo mais eficaz.
Para o desenvolvimento dos jogos foram utilizados utilizadas as ferramentas de desenvolvimento recomendada pelas produtoras de cada tecnologia. Para o desenvolvimento do jogo no flash foi utilizado o Flex Builder 3 da Adobe, e para o desenvolvimento na plataforma Silverlight foi utilizado o Visual Web Develop 2008 Express Edition da Microsoft.CONCLUSÃO
O somatório do aprendizado de todas as disciplinas ministradas no terceiro período do curso de Análise e Desenvolvimento de Sistemas da UNOPAR possibilitou a criação deste trabalho que demonstra as principais características de um Banco de Dados II, Análise Orientada a Objetos II, Programação orientada a Objetos e Programação Web, que foi usado desde a Modelagem de banco de Dados a Programação web.
No desenvolvimento web é de extrema importância que a empresa ou o desenvolvedor faça uma análise profunda de qual tecnologia deve ser utilizada com base nas características do aplicativo a ser implementado.
Tendo em vista este cenário, as avaliações de custo benefício das plataformas analisadas referente a qualidade do produto e a facilidade de desenvolvimento mostraram os seguintes resultados:
Qualidade: Em relação a qualidade do produto final, o Flash demonstrou ser bastante superior ao Silverlight, apresentando um nível de interatividade com microfone e webcam que inexiste na tecnologia concorrente, além de possuir a capacidade de manipular som. Outra vantagem do Flash para o usuário final é que ele poderá interagir com aplicações Flash em praticamente qualquer sistema operacional, pois diferente do Silverlight que apenas dá suporte ao Windows e ao Mac OS X, o Flash também dá suporte ao Linux.
Produtividade: Quanto a produtividade o Flash também se mostrou superior à solução da Microsoft, pois apresentou um excelente nível de integração com outras ferramentas, além de possuir um modo de disponibilização de conteúdo mais simples, e como foi demonstrado nos testes prático é necessário escrever bem menos linhas de código no flash do que em Silverlight para desenvolver um software. 
	O estudo demonstra que o profissional da área de Análise e Desenvolvimento tem uma grande abrangência no mercado, tanto nas áreas comerciais como na área tecnológica com desenvolvimento de softwares.
REFERÊNCIAS
DEVMEDIA – CURSOS -http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408#ixzz3p9g5VtcJ – Acessado em 23/10/2015
ESCOLA TECNICA LAURO GOMES – ETC 
http://www.etelg.com.br/paginaete/downloads/informatica/apostila_uml.pdf – Acessado Em 23/10/2015
Universidade Federal de santa Catarina – Projetos https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf – Acessado Em 23/10/2015
Instituto Matemática e estatística da Universidade de São Paulo www.ime.usp.br/~jef/bd02 – Acessado Em 23/10/2015
Instituto Matemática e estatística da Universidade de São Paulo http://www.ime.usp.br/~jef/bd02 – Acessado Em 23/10/2015
Departamento de Informática – PUC do RIO http://www.inf.puc-rio.br/~inf1621/oo.pdf – Acessado Em 23/10/2015
ESPWEB – Especialização Web e mobile - http://www.espweb.uem.br/ – Acessado Em 23/10/2015