terça-feira, 28 de outubro de 2008

Sistema Construtor

1. Objetivo
O sistema atende aos funcionários da empresa quanto as suas dúvidas operacionais. Criará uma base de conhecimento acessível via WEB onde estarão cadastradas as melhores práticas de cada área e as soluções implementadas para cada ocorrência não prevista em tempo de projeto.

2. Descrição
Informações inseridas na base devem ser validadas por um supervisor, engenheiro ou arquiteto.
As informações cadastradas serão classificadas por área, competência e porte da obra.
Autenticação será efetivada pela matrícula, (identificação funcional), com senha.
As consultas estarão disponíveis para todos os usuários do sistema.
A validação positiva de uma nova informação será distribuída via sistema, onde todos os usuários serão notificados, quanto a sua existência.

3. Treinamento
Todos os usuários receberam treinamento ministrado pela empresa desenvolvedora do sistema.

4. Procedimento de Cadastro
Somente será permitido o cadastro pelos usuários mestre de obras, engenheiros ou arquitetos, este sendo validado pelo sistema através de matrícula e senha, abre uma ocorrência informando a área, competência e porte da construção, descrição e possível solução ou procedimento. Após a ocorrência é enviada para aprovação do superior imediato (ver procedimento de validação).
botar img aqui

5. Procedimento de Consulta
Partindo do operário: deve procurar o superior imediato, mestre de obra, passando a ele o problema constatado ou dúvida. O mestre de obra acessando um terminal de consulta do sistema verifica o cadastro do problema ou dúvida, caso não conste ele procura obter a solução e posteriormente registrando no sistema (verificar procedimento de cadastro), sendo o problema ou dúvida encontrado é exibido para visualização. Partindo do mestre de obra, engenheiro ou arquiteto, este, acessando um terminal de consulta do sistema verifica o cadastro do problema ou dúvida, caso não conste ele procura obter a solução e posteriormente registrando no sistema (verificar procedimento de cadastro), sendo o problema ou dúvida encontrado é exibido para visualização.


6. Procedimento de Validação
Todas as novas informações deverão ser verificadas, corrigidas e validadas pelo engenheiro ou arquiteto, quando uma nova informação for inserida no sistema esta será encaminhada para o responsável mediante cruzamento de dados (área e competência), e ficará pendente de validação. Sendo aprovado ou reprovado o solicitante será informado mediante visualização no sistema.

7. Autenticação
O usuário passar o crachá em um leitor óptico ou informa diretamente o código da matrícula e após a senha para autenticação no sistema.


Construtora

O Problema
Ao iniciar o desenvolvimento de um novo projeto e/ou execução de uma obra solicitada pela construtora, não repetir erros cometidos no passado aumentando as chances de sucesso ao mesmo. Erros recorrentes com soluções muitas vezes diferentes estão causando uma perda de rendimentos a empresa.

Solução
Como proposta de solução, foram levantadas três frentes distintas para cobrir todas as áreas de abrangência do sistema, sendo elas: workflow, catalogação e pesquisa de histórico.

Workflow

Entrada de dados:

Arquitetura:
a) Desenho Segundo especificações do cliente;
b) Tipo de arquitetura

Engenheiro:
a) Análise do desenho: aprova ou não
b) Ambiente natural do local;
c) Tipo de obra;
d) Quantidade de andares;
e) Tamanho da obra;
f) Quantidade de algum material utilizado na obra;
g) Custo da obra; 
h) Se não foi aprovado, vai pra Arquitetura para redesenho,
Se for aprovado, segue para o mestre de obras Mestre de obras:

a) Uso de ferramentas;
b) Problemas resolvidos;
c) Os profissionais que trabalharam na obra;
d) Fornecedores;
e) Marcas dos materiais utilizados;
f) Nível de segurança do local; 
g) Analise durante o desenvolvimento da construção :

Se houver problemas, cadastra os dados: 
Área específica, definida por ele, e a descrição do problema
Se não houver, continua.
Enquanto nào terminar a construição, fica na analise do mestre.

Catalogação.
Durante este processo, serão realizados os cadastros que dizem respeito ao momento da obra, tornando assim cada situação um novo dado histórico que permita ser consultado posteriormente. A catalogação se dará de forma categorizada, principalmente dividindo em três grandes grupos: peculiaridades encontradas, problemas insolúveis e problemas solúveis. Para cada uma destas três situações o atualizador terá o poder de tecer comentários a respeito de seu problema, e quais medidas foram tomadas na ocasião.

A catalogação não abordará apenas problemas técnicos, mas sim situações corriqueiras e principalmente identificará responsáveis pelas atividades e equipes envolvidas.
O cadastro de tais informações se dará a partir de um computador com acesso a internet, já que o sistema será web

Pesquisa
A parte de pesquisa constitui outra frente importante do sistema, já que será a partir dela que o executante terá base para tomada de decisões. Todos os dados que forem fornecidos durante a etapa de catalogação estarão acessíveis de acordo com o nível de acesso para consulta relatando quais as soluções tomadas.

Como é difícil encontrar um mesmo ambiente em duas situações a pesquisa exige que haja um sistema busca por palavras chaves, para que consiga filtrar as informações fornecidas e busque tais palavras nos projetos cadastrados anteriormente. Assim, baseado em quantidade de vezes que a palavra apareceu, poderá ser feita uma análise de relevância do resultado.
Dados como valores cobrados por fornecedores, quantidades de problemas ocasionados por profissionais (terceiros) específicos, marcas utilizadas, custos de obras e opiniões dadas por clientes também poderão ser consultadas para que se haja uma visão gerencial maior dos projetos.

A pesquisa será um sistema acoplado ao sistema de catalogação. Sendo assim, esta também se dará através de uma interface web.

Usuários do sistema
Inicialmente o foco de atendimento do produto serão os mestres de obras responsáveis pela construção, já que eles serão os concentradores da informação, advindas tanto por parte dos engenheiros quanto por parte dos técnicos (peão). Sua vivencia diária na obra lhe permitirá perceber quais os principais entraves vividos pelos funcionários e quais as soluções adequadas para as tais (geralmente tomadas pelo próprio mestre), permitindo assim alimentar o sistema com sua experiência e/ou ter uma boa base de conhecimento para realizar as pesquisas de histórico aos outros projetos.

Como os problemas não se concentram apenas na fase da execução, os engenheiros também podem/devem consultar o sistema para obter uma maior assertividade no desenvolvimento do projeto, para que tenha maior conhecimento até para que seja repassado aos mestres de obra posteriormente.

A parte executiva da empresa teria acesso ao sistema para tomada de decisões de acordo com o histórico, partindo de conhecimentos de falhas com equipes especificas ou determinados locais.
Por fim, o cliente poderá contribuir com idéias a respeito do que lhe foi entregue, apontando falhas perceptíveis a leigos, imperfeições visuais ou qualquer outro problema que ele tenha percebido após o término da obra.

O que deverá ser catalogado e poderá ser pesquisado?

Alguns dados importantes para serem cadastrados, para que assim fique mais fácil realizar a pesquisa bem como fazer o relacionamento de informações pela inteligência artificial:
-Ferramentas utilizadas durante as operações
-Profissionais envolvidos e suas respectivas tarefas
-Fornecedores
-Marcas utilizadas
-ambiente natural do local
-Segurança encontrada no local da obra
- tamanha da obra (metragem);
- custo da obra
- tipo de arquitetura

Interfaces
Para prover o cadastro de todas estas informações foram previstas as seguintes telas para o sistema:
-cadastro de atividades
-cadastro de funcionários
-cadastro de fornecedores
-cadastro de materiais
-Cadastro de plantas
-Cadastro de obra
-busca de atividades por palavra chave
-busca de atividades por profissionais
-busca de custo por projetos
-busca de profissionais por projetos
-busca quantidade de problemas por profissionais

Diagramas:

Caso de uso Geral



Diagrama de Sequência de Cadastro para pesquisa



Diagrama de Sequência de pesquisa



fluxograma do workflow

Sist. Ger. Construção

SISTEMA DE GERENCIAMENTO DE PROJETOS DE CONSTRUÇÃO CIVIL – SisCom

Introdução
Objetivo do sistema (SisCom) é gerenciar as informações de forma automatizada e acessível para minimizar perdas e retrabalho e maximizar a produtividade num projeto de construção civil.
O SisCom permitirá a interatividade das experiências dos profissionais de execução com os engenheiros de projetos, onde os engenheiros, na fase de desenvolvimento, poderão consultar os problemas e sugestões ocorridos nas obras. Esta interatividade acontece devido ao SisCom permitir que seja classificada a categoria da obra, o estágio, o tipo de serviço e o nível critico dos problemas encontrados.

Funções do Sistema
· Cadastrar, editar, excluir problemas;
· Cadastrar, editar, excluir sugestões;
· Pesquisar problemas através de filtros considerando:
o O tipo de imóvel;
o A etapa da obra;
o O estágio da obra;
o O nível da obra;
o Gravidade do problema da obra.
· Pesquisar sugestões;
· Gerar relatórios com as melhores sugestões;
· Gerar relatórios com os problemas ocorridos;

Características dos usuários
· Ter noções básicas de informática;
· O usuário deve ter um treinamento na ferramenta;
· Conhecer o processo de sua área.

Níveis de acesso dos Usuários
· Cadastramento de sugestões: Os usuários do SisCom podem inserir novos registros;
· Cadastramento de problemas: Será de acordo com função do funcionário;
· Pesquisas: Os usuários do SisCom podem pesquisar.

Exemplo da tela de cadastro de problema.

Projeto Engenharia SBBC

SISTEMA BASE DE CONHECIMENTO DA CONSTRUÇÃO

INTRODUÇÃO

Propósito

Este documento tem como objetivo definir os requisitos do projeto de base de conhecimento da construção, utilizando o cadastro e aprovação dos conhecimentos adquiridos na construção civil. Desta forma uma base de conhecimento é criada facilitando a evolução das obras.

Escopo

O sistema permite o cadastramento de informações pertinentes às construções que estão sendo realizadas, registrando conhecimento dos funcionários, desvios que aconteceram e melhorias que podem ser implementadas. Estas informações que serão registradas antes de terem sua publicação finalizada serão aprovadas por um profissional que tenha o conhecimento necessário para homologar os conhecimentos cadastrados.

Definições, Acrônimos e Abreviações

Mestre de obras: Profissional responsável pela obra e pelos pedreiros, como um coordenador.
Engenheiro: Responsável pela criação do projeto, desempenho, planta, etc.
Arquiteto: Responsável pela criação artística da obra.
SBCC: Sistema Base de Conhecimento da Construção

Organização da Especificação de Requisitos de Software

Este documento está dividido em quatro seções. Na Seção 1, uma breve introdução sobre o conteúdo deste documento foi apresentada. Na Seção 2, uma descrição geral do sistema é apresentada. Na Seção 3, os requisitos específicos do SBCC são descritos. Na seção 4 e final temos uma breve descrição do pós implantação.

Descrição Geral do Sistema

O sistema SBCC tem como principal objetivo o cadastro dos conhecimentos e habilidades adquiridas conforme a experiência de cada funcionário da construção civil. Com este sistema será possível a criação de uma base de conhecimento para as futuras construções garantindo assim a qualidade e a preservação da informação. Serão necessárias reuniões diárias de no máximo 15min entre os funcionários e coordenações para alinhar idéias novas a serem cadastradas e discussão de melhorias (Daily Scrum).

Funções do Produto

O SBCC tem como objetivo realizar o cadastro de informações das obras em andamento para uma base de conhecimento ser criada através das funções:
- Cadastro de novos conhecimentos/habilidades;
- Consulta das informações já cadastradas;
- Aprovação dos cadastros a partir de um profissional capacitado;
- Administração do sistema para a criação dos usuários, permissionamentos, ajustes iniciais do sistema, cadastro das áreas de conhecimento.

Características do Usuário

O SBCC é um sistema destinado aos profissionais da construção civil onde todos os envolvidos na construção poderão cadastrar informações, porém apenas usuários chaves e capacitados poderão fazer a aprovação para a publicação destas informações.

Suposições e Dependências

A configuração mínima requerida para a execução do SBCC são microcomputadores pessoais, memória RAM mínima de 128 Mbytes e ambiente Windows 98 ou superior. Além disso, deve conte um navegador (browser) instalado.

Requisitos Funcionais

- O sistema deverá realizar o cadastro de novos conhecimentos, será cadastrado na parte de Incidentes (para desvios que ocorrerão e são conhecidos) e melhorias (melhorias sugeridas para evitar desvios e/ou problemas e manter a qualidade do serviço). Para realização do cadastro será necessária a descrição da ocorrência, pessoa que cadastrou, detalhamento da ocorrência, função da pessoa que cadastrou;
- O sistema deverá possuir um cadastro de usuários, onde serão cadastradas todas as informações do usuário, tais como, matricula, função, nome, idade, experiência, tempo de empresa;
- O sistema deverá realizar pesquisa na base de conhecimento;
- O sistema deverá conter o cadastro de aprovadores por área de conhecimento/responsabilidade;
- O sistema deverá conter a parte de aprovação dos documentos cadastrados, esta pessoa será designada por áreas especificas de conhecimento. A pessoa que definirá quem aprova o que em cada área será o gestor do projeto;

Requisitos de Desempenho

- O sistema deverá apresentar tempo de resposta satisfatório para todas as funções requisitadas pelo pesquisador.

Atributos do Sistema de Software

- O sistema será WEB;
- O sistema possuirá portlets para a consulta rápida;
- O sistema possuirá um Faq e um Wiki para melhor discutir as idéias;
- Sistema deverá ser portátil;
- O sistema deve fornecer uma interface amigável e de fácil utilização.

Diagramas

Diagrama de Casos de Uso:




Diagrama de Atividade:

















Interface







Pós implantação

Serão realizados treinamentos com os multiplicadores para que o sistema seja apresentado e compreendido de forma plena. Estes treinamentos tem por objetivo tirar dúvidas e fazer com que os usuários entendam de forma plena o software, tendo assim um primeiro contato com o sistema.

sábado, 18 de outubro de 2008

Projeto Orientado a Objetos

Por ECP360 e BSI360 2008/2

1. Introdução a POO

A programação orientada a objetos veio para solucionar vários problemas que a programação comum não conseguia ou resolvia de forma incompleta. Trata-se de uma linguagem robusta com uma característica de reaproveitamento de código, melhor organização, desta forma facilitando a vida de programadores e analistas graças às facilidades que este tipo de linguagem proporciona.
Temos hoje no mercado diversas ferramentas para programação da POO, mas nem todas são exploradas ao máximo ou da forma correta, muito ainda neste setor existe para ser explorado, descoberto e desenvolvido.

Claro que mesmo sendo tão eficiente e tendo tantos recursos a POO ainda tem pontos de falha e que devem ser tratados. Não apenas as limitações podem trazer problemas para o desenvolvimento, mas ainda existe a limitação de quem desenvolve, sendo que muitas vezes algumas pessoas não estão preparadas e não tem conhecimento suficiente da estrutura orientada a objeto e acaba fazendo o mau uso da mesma e neste caso uma codificação ruim pode ser fatal para o programa.

Este é um assunto muito abrangente e causa muitas discussões, porém sempre é importante debater assuntos deste nível. Sempre é importante estudar um pouco mais sobre um assunto tão abrangente e tentar entender cada vez mais seus conceitos e fundamentos.

Objetos:

Objetos são elementos como na vida real, eles tem propriedades, estados, ações e partes. Um exemplo é um carro que possui quatro rodas que formam as partes do mesmo ou fazem parte de outros objetos, propriedades como potência do motor, estados como ligado/desligado e ações como acelerar.

Na POO, os objetos seguem a mesma linha, com objetos possuindo propriedades, outros objetos internos, como o exemplo do carro e métodos que definem seu comportamento.

Classes:

A classe pode ser definida como uma família onde todos os elementos contidos nesta seguem uma estrutura e funções definidas. Em relação à programação, a classe define os atributos e funções do objeto, então, ela descreve um conjunto de objetos semelhantes.

Todo objeto criado a partir de determinada classe é uma instância dessa classe, pois todas as informações contidas no objeto serão estruturadas de acordo com a classe.

A existência da classe proporciona uma organização e reusabilidade do código, caso não houvesse a classe em cada nova criação do objeto haveria a necessidade de descrever toda a estrutura desse novo objeto, assim, com o uso de classes pode-se padronizar os objetos.

Vantagens:

Reuso de código: É sem dúvida a maior vantagem da POO, pois permite que programas sejam escritos rapidamente garantindo que os mesmos estejam livres de erros, pois já foram testados anteriormente. Esta técnica é possível através de mecanismos de herança e interface.

Escalabilidade: É a capacidade de uma aplicação crescer sem aumentar sua complexidade ou comprometer seu desempenho. Graças à estrutura de objetos e classes, cada entidade do sistema agrupa suas funcionalidades específicas e se comunica com outras partes por mensagens.

Manutenção Fácil: É seguro, portanto mais fácil de manter. O encapsulamento ajuda a proteger as informações de cada classe, de modo que apenas seus objetos tenham acesso às informações que quando disponibilizadas externamente necessitam do consentimento do criador.

Apropriação: Polimorfismo permite tornar o programa mais enxuto, já que um método pode receber uma referência genérica e executar operações genéricas dessa classe. Graças ao mecanismo de interface e herança o sistema, fica em termos de manutenção, mais fácil de ser entendido e modificado.

Desvantagens:

Apropriação: É tanto uma vantagem quanto desvantagem. O mecanismo de interfaces e heranças quando utilizado de maneira errada, pode mais prejudicar do que ajudar sua aplicação. Na vida real é muito fácil dividir o mundo em categorias e grupos, na POO essa associação nem sempre é tão simples.

Fragilidade: Se os relacionamentos entre as classes mudam, muitas vezes é necessário remodelar o código e reprojetar uma nova hierarquia de classes. Se existir alguma falha durante esse processo, pode ser que o mesmo não seja tão facilmente identificado.

Linearidade de Desenvolvimento: O desenvolvimento precisa seguir uma linha e passar por todas as etapas de um projeto possível. Precisa que cada processo faça sua parte bem feito, porque uma é altamente dependente da outra. Além disso, a POO necessita de um projeto cuidadoso de hierarquia de classes, um erro aqui pode comprometer o bom desenvolvimento de toda uma aplicação.

2. UML (Unified Modeling Language)

História
A UML teve inicio após uma tentativa de Jim Rumbaugh e Grady Booch de relacionar dois métodos populares de modelagem orientada a objeto. O primeiro método é o Booch e o segundo é OMT (Object modeling language), esta união ocorreu no ano de 1994. Logo após essa parceria no ano de 1996 o criador do método Objectory juntou-se aos dois formatos (Booch e OMT), formando assim a primeira versão da linguagem UML(Unified Modeling Language).

Objetivos da UML
A UML tem como objetivos a modelagem de sistemas usando conceitos da orientação a objetos. Outro critério é estabelecer uma união com métodos conceituais que sejam executáveis.
A criaçao de uma linguagem de modelagem usável tanto pelo homem quanto pela máquina também é um dos objetivos da UML.

Futuro da UML
Pelo fato da UML ter como base técnicas antigas e marcantes da orientação de objetos, outras linguagens influenciarão as novas versões.
Técnicas avançadas de modelagem também podem ser definidas usando como base UML, estendendo-a, sem necessidade de redefinir a estrutura interna.
A UML tem integrado muitas idéias, e esta integração contribui para o desenvolvimento de softwares orientados a objetos.

Conceito UML
UML é uma linguagem que presa pela gestão visual para modelar um sistema orientado a objeto. Prezando por três perspectivas:
• Diagrama de classses – (dados estruturais);
• Diagramas de caso de uso – (operaões funcionais);
• Diagramas de seqüência, atividades e transição de estados – (eventos temporais);

Ele utiliza dos diagrmas para estar explicando um sistema. Onde tem como partes fundamentais os Atores e os Use Cases. Que por sua vez fazem toda a interação do sistema.
Temos assim os atores como as partes interativas do sistema (pessoas, dispositivos e outros). Já os use cases são as ações que interagem os atores.
Fica assim modelado o uso dos use case e os atores nos diagramas para uma apresentação detalhada do sistema.

O uml possui esses e outros elementos para criar os diagramas, para poder representar uma determinada parte do sistema ou um ponto de vista do sistema. Temos os seguintes diagramas:
- Caso de uso que vem mostrar os atores e seus relacionamentos;
- Classe que mostra o relacionamento entre as classes;
- Seqüência mostra os objetos e uma sequencia das chamadas do método feito para outros objetos;
- Colaboração mostra os objetos e seus relacionamentos, dando enfase aos que trocam mensagens;
- Estado mostra a mudança de estado e eventos num objeto ou parte do sistema;
- Atividade mostra as atividades ou troca de atividades em uma parte do sistema;
- Componente mostra a programação de alto nível;
- Distribuição mostra a instância dos componentes e seus relacionamentos;

Elementos da UML
De estrutura:
Modelação de estrutura ou Structure Modeling são as partes estáticas de um modelo, representando elementos conceituais ou físicos.
É neste modelo que entram os conceitos de:
• Classe
• Interface
• Componente
• Colaboração
• Nó

De comportamento:
É a modelação do comportamento (o estado) e troca de mensagens de vários tipos de sistemas, é usado, geralmente, para criar ferramentas para estudar estes comportamentos em situações extremas, sem ter que aplicar estas condições pelo fato de, por exemplo, ser muito caro este tipo de teste. Dentro deste Modelo podem ser aplicados os diagramas de Sequência, colaboração, transição de dados e atividades.

É neste modelo que entram os:
• Casos de uso
• Interação
• Máquina de estados

De agrupamento:
Modelação de agrupamento é a organização da UML do projeto em grupos.
Neste modelo entram os conceitos de:
• Pacote
• Modelo
• Subsistema
• Framework

De anotação:
Modelação por anotação são todas as partes explicativas do UML, neste modelo são utilizados todos os comentários que foram feitos e documentados no decorrer do projeto para descrever, detalhar e remarcar todos os elementos no modelo.
Neste modelo entra o conceito de:
• Notas

Relacionamentos
• Dependência
• Associação (bidirecional ou unidirecional)
• Generalização
• Agregação
• Composição

Uma dependência indica a ocorrência de um relacionamento entre dois ou mais elementos do modelo, onde uma classe cliente é dependente de alguns serviços da classe fornecedora, mas não tem uma dependência estrutural interna com esse fornecedor.Por exemplo, Uma mudança no elemento independente irá afetar o modelo dependente. Como no caso anterior com generalizações, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante.

Quando uma classe recebe um objeto de outra classe como parâmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependência entre estas duas classes, apesar de não ser explícita.

Associação são relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes.

A associação pode existir entre classes ou entre objetos. Uma associação entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina. Esta relação significa que as instâncias das classes são conectadas, seja fisicamente ou conceitualmente.

Generalização é a capacidade de se criar superclasses que encapsulam estrutura e/ou comportamento comuns a várias subclasses. Os procedimentos para se obter a generalização são:
• Identificar similaridades de estrutura/comportamento entre várias Classes.
• Criar a superclasse para encapsular a estrutura/comportamento comum.
• As classes originais passam a ser subclasses da nova superclasse criada.

Uma maneira relativamente fácil de se entender isso, é comparando com a nossa herança genética: Você possui algumas características de seus Pais. Mas seus Pais não possuem suas características. Pois bem, você seria uma subclasse.

Agregação é uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo.

É representada como uma linha de associação com um diamante junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

Composição é uma agregação onde uma classe que está contida na outra "vive" e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de composição serão destruídas juntamente, já que as mesmas fazem parte da outra.
É representada como uma linha de associação com um diamante preenchido junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

3. Comunicação de objetos

RPC
Chamada de procedimento remoto (ou RPC, Remote Procedure Call) é uma tecnologia de comunicação entre processos que permite um programa de computador chamar um procedimento em outro espaço de endereçamento. O programador não se preocupa com detalhes de implementação dessa interação remota. O metodo remoto é invocado da mesma maneira que um metodo local.

RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para uma servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia de que o procedimento foi invocado.

RMI
O RMI (Remote Method Invocation) é uma interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java. É uma forma de implementar um sistema distribuído em plataforma Java. A grande vantagem do RMI em relação ao RPC se dá ao fato de ser possível invocar métodos de objetos remotos e transferir objetos entre estes.

Herança
É o mecanismo pelo qual uma classe herda os atributos/métodos de outras. Assim, uma característica implementada em uma classe pode ser "copiada" para a outra sem reescrever o código.
Utilizando herança, têm-se os seguintes relacionamentos:

• Subclasse: É a classe “filha” que herda de uma ou mais classes suas caracteristicas.
• Superclasse: É a classe “pai”, da qual outras classes irão herdar as características
Herança Simples x Herança Múltipla
• Quando uma classe é subclasse de apenas uma superclasse, essa é uma herança simples.
• Quando uma subclasse herda de duas ou mais superclasses, essa é uma herança múltipla.

Problemas Herança Múltipla
Apesar de ser mais "poderosa" que a herança simples, por permitir que uma classe herde as características de diversas classes, a herança múltipla traz alguns problemas: O que fazer quando as superclasses têm características "conflitantes"?
Isso é chamado de problema diamante.

Interface
É um “contrato” no qual todas as classes que o programam devem seguir. Descreve as características externas (publicas) que uma classe tem. Nelas contem as assinaturas de métodos (nome, parâmetros e valor de retorno). Dessa forma, todas as classes que implementam uma interface, devem implementar os métodos nela contidos.

Polimorfismo
O polimorfismo permite que uma classe seja tratada como uma de suas superclasses ou como uma interface que ela implementamodelo das classes a qual foi concretas a qual foi referenciada. Assim, um mesma classe pode apresentar várias formas. O termo polimorfismo tem o significado de "muitas formas" (poli = muitas, morphos = formas).

Digamos que exista uma classe responsável por caracterizar um objeto GERENTE, porem o objeto Gerente herda caracteristicas do objeto EMPREGADO que o mesmo herda de PESSOA. O Polimorfismo nos oferece a mobilidade de lidar com nosso objeto GERENTE em qualquer formato de objeto do qual foi herdado, tanto com seus atributos como com seus metodos.

Associação
São relações entre classes, representando a possibilidade de relação entre os objetos, permitindo que um objeto utilize os recursos de outro, podendo existir mais de uma associação.
Por exemplo: uma pessoa abre a porta; a maçaneta faz parte da porta.

Coesão
Coesão é uma medida de integridade conceitual de uma classe - o objetivo, nesse caso, é o de maximizar a coesão para assegurar agrupamento de operações e com isso reduzir esforços de manutenção.

Encapsulamento
Um dos pontos da POO é o de esconder dados dentro de Objetos, os quais são manipulados por funções(Métodos). Estas estruturas não devem ser visíveis para outros objetos, apenas pelos métodos dentro do objeto à que ele pertence, aos outros objetos somente aparecem os métodos existentes. Na classe são criados atributos(Estruturas de dados) para o armazenamento de uma maneira privada e são implementados métodos (públicos) que manipulam estas estruturas.

Acoplamento
O acoplamento é uma medida de quanto uma classe esta ligada a outras classes, tendo conhecimento das mesmas ou sendo dependente delas.
Uma classe com baixo (fraco) acoplamento não depende de muitas outras.
Uma classe com alto (forte) acoplamento é:

• Mais difícil de compreender isoladamente;
• Mais difícil de reutilizar (seu uso depende da reutilização das outras classes da qual ela depende);
• Sensível a mudanças nas classes associadas

4. Tipos de objetos

Servidores: O objeto servidor tem a função de servir a um outro objeto que possa se fazer necessário em um determinado momento. Enquanto um objeto servidor não está servindo a um outro objeto sua execução é interrompida até que esse se torne necessário novamente. Um exemplo que podemos usar é: um determinado objeto tem um método de impressão, ele só se fáz necessário no momento em que o usuário deseja imprimir algum documeto. Quando esta necessidade existe este objeto é chamado e utilizado, porém enquanto ninguém necessitar o seu uso ele continua parado.

Objetos concorrentes: Objetos concorrentes são quando dois objetos estão executando processos de forma simultânea, e inclusive podem se comunicar-se um com o outro. Porém eles são independentes e executam as suas atividades de forma separada. Um exemplo seria o uso de threads, onde é possível criar dois processos concorrentes que executem duas tarefas diferentes em um mesmo programa, e ainda uma esperando uma determinada resposta da outra quando necessário.

Objeto Ativo: é o objeto que executa as atividades, ele é o objeto responsável pela linha de execução. É ele que executa as tarefas quando estimulado.Ele sempre está em modo de execução, ao contrário do objeto do tipo servidor pois está sempre sendo executado.

Objeto Passivo: o objeto que é desprovido de capacidade de execução, sua função é basicamente enviar estímulos a objetos ativos para que eles por sua vez executem alguma atividade. Um exemplo seria um sensor que recebe um sinal de temperatura alta indicando um incêndio. Porém o sensor em sí não tem capacidade de apagar o fogo, assim ele estimula o
sistema anti-chamas a fazer a extinção do fogo.

5. Rational Unified Process (RUP)

É um processo proprietario de engenharia de software criado pela Rational Software Corporation posteriormente adquirido pela IBM. Trata-se de uma metodologia utilizada para gerenciar grandes projetos de software, utilizando uma abordagem de orientação de objetos e a notação UML para sua documentação.

Características:
• Uso de iterações para evitar o impacto de mudanças no projeto,
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

Fases do projeto:
• Concepção - entendimento da necessidade e visão do projeto,
• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema

O RUP se baseia nos 4 P’s
• Pessoas
• Projeto
• Produto
• Processo

As fases do projeto são compostas de uma ou mais iterações, sendo semelhante ao modelo espiral. As iterações são definidas em um determinado período de tempo geralmente curtos.
Conteúdo do RUP

Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos.

Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.

Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário.

Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artifacts) gerados ao longo do projeto. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.

Análise de risco – Consiste em analizar os possiveis riscos durante o projeto, procurando metodos para evita-los ou trata-los.

Gestão de mudança – a gestão de mudança visa lidar com as mudanças de requisitos ao longo do projeto.

6. Identificação de Objetos

Identificação de objetos é o processo de análise para identificação e modulação dos objetos e classe de um sistema. Esta tarefa não é fácil, pois requer que o projetista tenha habilidade e experiência sobre os processo que envolvem a utilização do sistema, além de não ter um método específico, mas apenas um conceito.

Abaixo é descrito um exemplo que servirá de base para o entendimento do assunto.
"Uma empresa solicita o desenvolvimento de um software que faça o gerenciamento do Recursos Humanos da empresa. Para isto, foram determinados certas regras, na qual o empregado possui uma identidade própria, seu nome. Possui também propriedades como: endereço, idade, dependentes, salário, cargo. Neste sistema também são encontrados avaliações que os empregados realizam. O RH organiza eventos da empresa para seus colaboradores, dependentes e a sociedade. No sistema o comportamento pode ser determinado por operações como: aumentar salário, listar dependentes e alterar cargo. As propriedades somente podem ser manipuladas através das operações definidas na interface do objeto, de modo que a forma de armazenamento das propriedades e a implementação das operações são desconhecidas pelas outras entidades externas."

Para identificamos objetos ao um sistema é interessante enxergamos o primeiramente mundo real assim como na história acima o mundo real é o setor de recursos humanos, então deve-se olhar os processos envolvidos no RH.

Pode-se identificar no exemplo acima o objeto Empregado, na qual carrega as seguintes propriedades: endereço, idade, dependentes, salário. Também é identificado o objeto Avaliação que pode carregar as seguintes propriedades: nome, tipo de avaliação, pré-requisitos.

Alguns objetos são considerados abstratos, pois não são objetos palpáveis. Estes objetos são mais difíceis de enxergar, no exemplo citado existe dois objetos abstratos: Evento e Cargo, onde as propriedades para Evento são: nome do evento, tipo de evento, freqüência, quantidade de convidados; e para Cargo: nome do cargo, nível do cargo, salário base do cargo.

7. Modelos de Projeto

Os modelos de projetos mostram as classes de objetos e as relações entre elas. São divididos em modelos estáticos e modelos dinâmicos.

Os modelos estáticos descrevem basicamente a estrutura estática do sistema e como elas se relacionam.

Os modelos dinâmicos por sua vez, descrevem a interação dos objetos em tempo de execução.

Eles não precisam ser necessariamente UML, podem ser modelos RUP ou modelos próprios.

Exemplos de modelos UML:

Modelo de caso de uso (estático):

Modelo de Subsistema (estático): Mostra como o projeto é organizado em grupos de objetos relacionados.

Modelo de sequência (dinâmico): modelam a seqüência das interações entre os objetos.



Modelo de Estado (dinâmico): mostram os estados dos objetos individuais.

Modelo de transição (estático): é uma representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema.



Modelo de atividades (dinâmico)

Diagrama de colaboração (dinâmico)