quarta-feira, 28 de março de 2012

Como fazer uma resenha


Todo mundo que frequenta uma faculdade deve (ou devia) está acostumado a ler várias resenhas toda semana, mas afinal, o que é e o que precisamos saber para escrever um texto desse tipo?
Como um gênero textual, uma resenha nada mais é do que um texto em forma de síntese que expressa a opinião do autor sobre um determinado fato cultural, que pode ser um livro, um filme, peças teatrais, exposições, shows etc.
O objetivo da resenha é guiar o leitor pelo emaranhado da produção cultural que cresce a cada dia e que tende a confundir até os mais familiarizados com todo esse conteúdo.
Como uma síntese, a resenha deve ir direto ao ponto, mesclando momentos de pura descrição com momentos de crítica direta. O resenhista que conseguir equilibrar perfeitamente esses dois pontos terá escrito a resenha ideal.
No entanto, sendo um gênero necessariamente breve, é perigoso recorrermos ao erro de sermos superficiais demais. Nosso texto precisa mostrar ao leitor as principais características do fato cultural, sejam elas boas ou ruins, mas sem esquecer de argumentar em determinados pontos e nunca usar expressões como “Eu gostei” ou “Eu não gostei”.

Tipos de Resenha

Até agora eu falei sobre as resenhas de uma forma geral e livre e esses dados são suficientes para você já esboçar alguns parágrafos.
Contudo, as resenhas apresentam algumas divisões que vale destacar. A mais conhecida delas é a resenha acadêmica, que apresenta moldes bastante rígidos, responsáveis pela padronização dos textos científicos. Ela, por sua vez, também se subdivide em resenha críticaresenha descritiva e resenha temática.
Na resenha acadêmica crítica, os oito passos a seguir formam um guia ideal para uma produção completa:
  1. Identifique a obra: coloque os dados bibliográficos essenciais do livro ou artigo que você vai resenhar;
  2. Apresente a obra: situe o leitor descrevendo em poucas linhas todo o conteúdo do texto a ser resenhado;
  3. Descreva a estrutura: fale sobre a divisão em capítulos, em seções, sobre o foco narrativo ou até, de forma sutil, o número de páginas do texto completo;
  4. Descreva o conteúdo: Aqui sim, utilize de 3 a 5 parágrafos para resumir claramente o texto resenhado;
  5. Analise de forma crítica: Nessa parte, e apenas nessa parte, você vai dar sua opinião. Argumente baseando-se em teorias de outros autores, fazendo comparações ou até mesmo utilizando-se de explicações que foram dadas em aula. É difícil encontrarmos resenhas que utilizam mais de 3 parágrafos para isso, porém não há um limite estabelecido. Dê asas ao seu senso crítico.
  6. Recomende a obra: Você já leu, já resumiu e já deu sua opinião, agora é hora de analisar para quem o texto realmente é útil (se for útil para alguém). Utilize elementos sociais ou pedagógicos, baseie-se na idade, na escolaridade, na renda etc.
  7. Identifique o autor: Cuidado! Aqui você fala quem é o autor da obra que foi resenhada e não do autor da resenha (no caso, você). Fale brevemente da vida e de algumas outras obras do escritor ou pesquisador.
  8. Assine e identifique-se: Agora sim. No último parágrafo você escreve seu nome e fala algo como “Acadêmico do Curso de Letras da Universidade de Caxias do Sul (UCS)”
Na resenha acadêmica descritiva, os passos são exatamente os mesmos, excluindo-se o passo de número 5. Como o próprio nome já diz, a resenha descritiva apenas descreve, não expõe a opinião o resenhista.
Finalmente, na resenha temática, você fala de vários textos que tenham um assunto (tema) em comum. Os passos são um pouco mais simples:
  1. Apresente o tema: Diga ao leitor qual é o assunto principal dos textos que serão tratados e o motivo por você ter escolhido esse assunto;
  2. Resuma os textos: Utilize um parágrafo para cada texto, diga logo no início quem é o autor e explique o que ele diz sobre aquele assunto;
  3. Conclua: Você acabou de explicar cada um dos textos, agora é sua vez de opinar e tentar chegar a uma conclusão sobre o tema tratado;
  4. Mostre as fontes: Coloque as referências Bibliográficas de cada um dos textos que você usou;
  5. Assine e identifique-se: Coloque seu nome e uma breve descrição do tipo “Acadêmico do Curso de Letras da Universidade de Caxias do Sul (UCS)”.

Conclusão

Fazer uma resenha parece muito fácil à primeira vista, mas devemos tomar muito cuidado, pois dependendo do lugar, resenhistas podem fazer um livro mofar nas prateleiras ou transformar um filme em um verdadeiro fracasso.
As resenhas são ainda, além de um ótimo guia para os apreciadores da arte em geral, uma ferramenta essencial para acadêmicos que precisam selecionar quantidades enormes de conteúdo em um tempo relativamente pequeno.
Agora é questão de colocar a mão na massa e começar a produzir suas próprias resenhas!

Observação: esse texto foi copiado do website http://www.lendo.org

sábado, 24 de março de 2012

Diagrama de Atividades - QUESTÃO 2

QUESTÃO 2 - Construa um Diagrama de Atividades para o seguinte processo de negócio:

  1. A autorização do pagamento tem início após um pedido ter sido realizado pelo cliente. 
  2. Ao mesmo tempo, a disponibilidade para cada um dos itens do pedido é verificada pelo depósito. 
  3. Se a quantidade requisitada de um determinado item existe em estoque, tal quantidade é associada ao pedido, caso contrário, a quantidade do item será alterada (se houver em quantidade menor), se a quantidade em estoque for igual a zero, o item será excluído. 
  4. O pedido é enviado pelo depósito ao cliente quando todos os itens estiverem associados e o pagamento estiver autorizado. 
  5. O pedido será cancelado se a ordem de pagamento não tiver sido autorizada.

OBS. Pode facilitar a compreensão se utilizar a numeração do passo e o mesmo texto do fluxo.


RESPOSTA:





Diagrama de Atividades - QUESTÃO 1


QUESTÃO 1 - Leia interprete a descrição do caso de uso abaixo e complemente a sua especificação através de um Diagrama de Atividades:

Projeto: Controle de Cursos
Nome: Manter Aluno
Descrição: Este caso de uso permite a inclusão, exclusão, alteração e consulta de alunos, pela atendente
Ator: Atendente
Pré-condição: A atendente deverá estar devidamente identificada pelo sistema
Fluxo Principal:

1. A Atendente informa o código do aluno [A1]
2. A Atendente solicita a busca
3. O sistema pesquisa os dados do aluno
4. O sistema exibe os dados do aluno [A2]
5. A Atendente edita os dados do aluno [A3]
6. A Atendente solicita a gravação dos dados
7. O sistema valida os dados informados
8. O sistema grava os dados do aluno [A4]
9. Fim do caso de uso

Fluxos Alternativos:

A1. Novo Aluno
1. A Atendente solicita a inclusão de um novo aluno
2. O sistema solicita os dados do novo aluno
3. A Atendente informa os dados do aluno
4. Vai para o passo 6 do fluxo principal

A2. Aluno não encontrado
1. O sistema informa a situação à atendente
2. Vai para o passo 1 do Fluxo Principal

A3. Exclusão de Aluno
1. Atendente solicita exclusão do aluno
2. O sistema solicita confirmação da exclusão
3. [se confirmação positiva] Sistema exclui aluno
4. Vai para o passo 9 do fluxo principal

A4. Dados inválidos
1. Se algum dado do aluno estiver em desacordo com as regras de validações e restrições, o sistema informa situação à Atendente.
2. Vai para o passo 5 do fluxo principal

Pós-condições: Os dados são incluídos, alterados ou excluídos conforme solicitação do aluno

Restrições e Validações: 1. Nenhum campo poderá ser deixado em branco
2. O campo CPF deverá ser preenchido somente com números
3. O ano de nascimento deverá ser informado com 4 dígitos


Resposta:


Observem que usei raias. Poderia não ter usado, mas assim ficou bem mais explicado, permitindo que a atividade represente as atividades responsáveis do atendente e do sistema.

Boa sorte e bons estudos.
Fiquem com Deus.

Diagrama de Atividades - QUESTÃO 3


Questão 3 - Analise o Diagrama de Casos de Uso abaixo, referente a um módulo de matrícula e construa um Diagrama de Atividades para demonstrar modelagem dos processos do negócio.









Resposta:


Essa questão não passei para vocês, porque o tempo foi curto.

Bons estudos e fiquem com Deus.

Diagrama de Atividades - DESCRIÇÃO DE UMA REGRA DE NEGÓCIO

DESCRIÇÃO DE UMA REGRA DE NEGÓCIO


  1. A nota de um aluno em uma disciplina (um valor de 0 a 10) é obtida pela média de duas avaliações durante o semestre, A1 e A2, ou pela freqüência nas aulas.
  2. Se  o  aluno  obtiver  nota maior  ou  igual  a  7.0  (sete), será aprovado.
  3. Se o aluno obtiver nota maior ou  igual a 5.0  (cinco) e menor que 7.0 (sete), deverá fazer a avaliação final.
  4. Se  o  aluno  obtiver  nota  menor  que  5.0  (cinco)  será reprovado.
  5. Se o aluno obtiver uma freqüência menor que 75% em uma turma, será automaticamente reprovado.
  6. Após  a  prova  final,  o  aluno  será  considerado aprovado, se sua média  final  for maior ou  igual a 6.0 (seis), caso contrário, será reprovado.


EXEMPLO - MODELAGEM DA LÓGICA DE UMA REGRA DE NEGÓCIO








quinta-feira, 22 de março de 2012

Introdução a Sistemas de Informação

Pessoal, no mundo globalizado e digital que vivemos é de fundamental importância que o profissional de tecnologia tenha propriedade em escolher um sistema de informação, as tecnologias envolvidas, o tempo e sobretudo os custos e benefícios para uma ou mais demandas especificas.

Nesse sentido, temos direcionado o conteúdos das aulas estarmos aptos a atender a essas e outras indagações que eventualmente possam surgir.

Portanto, recomendo urgentemente que tenhamos mais impeto e fome para adentrar nesse mundo de cabeça. Assim, é preciso inicialmente compreender muito bem os conceitos que envolvem as organizações, as pessoas e a tecnologia destacando o conceito de dados, informação, conhecimento, o porquê as organizações precisam de sistemas de informação, a teoria geral e origem dos sistemas, classificação dos sistemas de informação.

Posteriormente, novos conhecimentos serão passados e cobrados para atingirmos nosso objetivo macro que é atender a crescente demanda do mundo digital e globalizado.

Abaixo segue material de estudo, disponível em  http://paginas.ucpel.tche.br


SISTEMAS DE INFORMAÇÃO

Atenção: conforme alertado na última aula, não se esqueçam de levar todo material possível sobre todo o conteúdo dado , bem como sobre os trabalhos e apresentações já solicitados.

Boa sorte. Fiquem com Deus.

quarta-feira, 21 de março de 2012

Engenharia de Software II

Pessoal, veja o interessante texto sobre Reuso de Software publicado em 2007 no website http://www.newtonbragarosa.com.br.

REÚSO DE SOFTWARE GERA OTIMIZAÇÃO DOS RECURSOS


Patrícia KnebelOtimizar tempo e reduzir custos são as premissas que estão fazendo com que a estratégia de reutilização de software cresça no mundo e, aos poucos, ganhe força no Brasil. A lógica está em criar uma espécie de biblioteca com práticas e rotinas que possam ser repetidas em alguns estágios do desenvolvimento dos programas pelas fábricas de software e empresas em geral.
Para a professora da Faculdade de Informática da Pontifícia Universidade Católica do Rio Grande do Sul (Pucrs) Ana Paula Terra Bacelo não é mais compatível com a realidade de hoje do mercado a prática de começar do zero todos os projetos. "As corporações precisam ter um processo de desenvolvimento que permita o reuso, a partir da criação de componentes genéricos e que possam ser usados em aplicações específicas", afirma.
A universidade irá sediar, em 2008, o Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCCARS), que este ano está sendo realizado na Universidade de Campinas (Unicamp). A edição deste ano termina na sexta-feira. "Com esse evento, queremos disseminar o conceito de reutilização de software e avançar o estado da arte sobre desenvolvimento de componentes", afirma a coordenadora-geral do simpósio, Cecília Mary Fischer Rubira. Além disso, a idéia é estimular o contato da indústria com as áreas de engenharia de software, na busca por aplicabilidades e soluções que funcionem na prática.
A especialista da Pucrs explica que, para que seja possível a concepção de modelos que sigam esse conceito, devem ser criadas estruturas fixas nas quais os colaboradores possam consultar as bibliotecas e adaptar os sistemas para cada projeto. Entre os softwares nos quais o reuso vem sendo aplicado estão os de gestão e também os mais específicos, como para a área médica.
Essa estratégia, entretanto, ainda não é uma realidade no mercado brasileiro. "A diminuição do trabalho e da qualidade dos produtos é grande, porém, ainda não existe uma política de uso no País", observa. O contrário acontece nos países mais desenvolvidos, nos quais as exigências na manutenção dos índices de qualidade e produtividade perseguem os gestores.
A Digital Assets atua na implantação, com o conceito de reutilização de software dentro das empresas. São usados produtos e serviços para ajudar as áreas internas de Tecnologia da Informação (TI), de clientes como Embraer e Bank Boston, a usar esses processos no dia-a-dia.
Kleber Bacili, diretor de tecnologia, diz que soluções contribuem para a criação de repositórios através dos quais as companhias podem catalogar os procedimentos, rotinas e ferramentas usadas. "Trabalhamos muito com empresas cujo foco não é o desenvolvimento de software e, por isso mesmo, precisam otimizar o tempo", relata.
O presidente da Associação Sul-rio-grandense de Apoio ao Desenvolvimento de Software (Softsul), José António Antonioni, acredita que o mercado deverá demandar mais esse tipo de solução nos próximos anos, principalmente as fábricas de software. "Ao ter componentes previamente construídos, testados e validados, as empresas têm um menor esforço de desenvolvimento e reduzem custos", constata.
Segundo ele, entretanto, ainda existem questões tecnológicas que impedem que o reuso de software seja adotado em larga escala. Se um sistema estiver sendo construído usando a linguagem de programação Java, é mais complexo fazer uma reutilização se a continuação for através da .net. "Não é algo tão trivial, mas que, quando pode ser feita, traz inúmeras vantagens para as empresas", relata Antonioni. Soluções que ajudem na interoperabilidade dos sistemas, como Service Oriented Architecture (SOA) conseguem atenuar essa dificuldade entre as interfaces.
Fonte: Jornal do Comércio

sábado, 17 de março de 2012

Modelo Projeto UML

Pessoal, bom dia.

Abaixo segue um Modelo Projeto UML, para reforçar seus estudos.
Esse modelo é composto por alguns diagramas, documento de visão e documento de caso de uso.
Sigam esse modelo para desenvolvimento de suas atividades e terão muito sucesso.

Exemplo de documentação de requisitos de sistema

Pessoal, para quem esta com um pouco de dificuldade com relação a documentação dos requisitos de sistema, segue um exemplo.

http://vensso.sourceforge.net/doc/VENSSO_REQ_20050526.pdf

Em breve, estarei disponibilizando outros materiais complementares.

Boa sorte, bons estudos. Fiquem com Deus.

sexta-feira, 16 de março de 2012

TID I

Atividade para próxima aula:












  1. Cada equipe, deve preparar estudo tendo como foco o tema escolhido pela equipe e como a tecnologia pode ajudar esse tema. 
  2. A equipe deve fazer apresentação expositiva com slide, apontando o objetivo, características, tecnologias envolvidas, vantagens, desvantagens, aplicabilidade, justificar a viabilidade e, se possível, casos de sucesso. 
  3. Além da apresentação, deve ser produzido material impresso e eletrônico.
  4. Esse material, juntamente com os recursos usados para a apresentação (slide , filme, etc.) deve ser enviado para o e-mail do professor até a data da apresentação. 
  5. Será avaliada a participação individual de cada membro da equipe, da equipe como um todo, pontualidade , domínio do conteúdo pesquisado e organização (introdução, contexto, desenvolvimento, referências bibliográficas, conclusão, etc.) 
  6. A ordem da apresentação será definida por sorteio no dia. Portanto, todas as equipes devem estar preparadas. Será apresentada uma ou duas equipes por aula.
Bons estudos e boa sorte! Fiquem com Deus.

quarta-feira, 14 de março de 2012

A importância de documentar sistemas


Dados estatísticos mostram que de 47% a 62% do tempo gasto em manutenção de sistemas é despendido na tentativa de entender os aplicativos, e que ler código fonte custa 3,5 vezes mais do que ler a documentação. Mas não é só, os dados mostram ainda que:
  • 53% DOS DEFEITOS SÃO DESCOBERTOS EM TRECHOS TIDOS COMO CORRETOS;
  • 10% DOS DEFEITOS É DE LÓGICA;
  • 79% DOS DEFEITOS SÃO CAUSADOS POR ENTENDIMENTO INCORRETO.

Outros fatores demonstram, de forma definitiva, a importância da documentação de sistemas:

  • O NOVO MODELO ORGANIZACIONAL (ANALISTA VOLTADO A INFORMAÇÃO E PROGRAMAÇÃO ATRAVÉS DE FÁBRICA DE SOFTWARE) IMPLICA NA NECESSIDADE DE DOCUMENTAR SISTEMAS.
  • A DEMANDA PELO DESENVOLVIMENTO DE NOVAS SOLUÇÕES TEM FORÇADO A LIBERAÇÃO DE RECURSOS VALIOSOS ALOCADOS À MANUTENÇÃO DE SISTEMAS;
  • A BUSCA PELA QUALIDADE E PRODUTIVIDADE TEM LEVADO AS ORGANIZAÇÕES A DOCUMENTAREM SEUS PROCESSOS E SISTEMAS.

É interessante considerar que não basta apenas elaborar uma documentação inicial perfeita, é preciso também que a documentação elaborada acompanhe cuidadosamente as manutenções e alterações nos sistemas, para que seja mantida a integridade e confiança da informação contida na documentação.

Os principais objetivos são:

  1. GERAR A DOCUMENTAÇÃO NECESSÁRIA PARA O DESENVOLVIMENTO DE NOVOS SISTEMAS;
  2. DOCUMENTAR OS SISTEMAS EM OPERAÇÃO, A FIM DE POSSIBILITAR MANUTENÇÕES FUTURAS E GARANTIR A CONTINUIDADE OPERACIONAL;
  3. PERMITIR A TRANSPARÊNCIA E ADERÊNCIA DOS SISTEMAS AUTOMATIZADOS AOS NEGÓCIOS DA ORGANIZAÇÃO;
  4. APOIAR O SISTEMA DE “CONTROLE INTERNO E COMPLIANCE”;
  5. CAPTURAR E DOCUMENTAR AS REGRAS DO NEGÓCIO EMBUTIDOS NO SISTEMA;
  6. UNIFICAR A DOCUMENTAÇÃO DE SISTEMAS, INDEPENDENTE DE FERRAMENTA OU AMBIENTE DE DESENVOLVIMENTO.


Maiores informações, http://www.documentacaosistemas.com.br/sistemas/home/58-a-importancia-de-documentar-sistemas.html

Analise e Modelagem II

Atividade



1. A secretária eletrônica do exercício  anterior  (resposta acima) é ativada ao primeiro toque da campainha.
2. Revise o diagrama de estados para que ela atenda após cinco toques.
3. Se o telefone for atendido antes de cinco toques, a secretária nada fará.
4. Atente para a diferença entre cinco chamadas em que o telefone é atendido ao primeiro toque e uma chamada que toca cinco vezes.

Obs. Não se esqueçam das atividades de 1 a 10 (pág. 178) do livro "UML2".

Boa sorte.

sexta-feira, 9 de março de 2012

Introdução a Sistemas de Informação

Atividade

  1. Dividir a sala em equipes. Cada equipe deve abordar alguns tipos de sistemas de informação, de acordo com sorteio em classe. A equipe deve fazer apresentação expositiva com slide, apontando características, tecnologias, vantagens, desvantagens, uso indicado, exemplos e, se possível, um estudo de caso. Recomendo que seja feito comparações com outros tipos de sistemas de informação.
  2. Além da apresentação, deve ser produzido  material impresso referente a todos os modelos e suas respectivas abordagens. Esse material, juntamente com os recursos usados para a apresentação (slide , filme, etc.) deve ser enviado para o e-mail do professor até a data da apresentação.
  3. Será avaliada a participação individual de cada membro da equipe, da equipe como um todo, pontualidade , domínio do conteúdo e organização (introdução, contexto, desenvolvimento, referências bibliográficas, conclusão, etc.)
  4. A ordem da apresentação é definida no dia da apresentação por meio de sorteio.
Fiquem com Deus, bons estudos e boa sorte!

Grupos
Sigla
Descrição
·          Renata Peixoto
EIS
Sistemas de Informação para Executivos
·          Tailane Alves Lima Maia
ERP
Enterprise Resource Planning ou
·          Rodrigo Moura
SIG
Sistemas Integrados de Gestão Empresaria
·          Ana Paula Rodriguês

Outros sistemas



·          Saimon Gomes
SAD
Sistemas Apoio a Decisão
·          Igor Pinheiro
SGBD
Sistemas de Gerenciamento de Banco de Dados
·          Cristopher
DW
Data Warehouse
·          Daniel Duque


·          Antônio Gerlis
IA
Inteligência Artificial
·          Cesar Dutra
SE
Sistemas Especialistas
·          Carlos Augusto
DM
Data Mining
·          Nerival Neri


·          Tamires Escolático Correia
TPS
Sistemas de Processamento de Transação
·          Matheus Alves Santos
AE
Automação de Escritório
·          Jefferson Campos Souza Jr.
MIS
 Sistemas de Informação de Gestão
·          Jefferson da Silva Santos
MIS


quinta-feira, 8 de março de 2012

Engenharia de Software II


Parabéns a todas as equipes!

Caros, meus elogios pelas apresentações sobre processos de software.
As considerações e maiores detalhes a respeito já foram feitos em classe.
Tenho certeza que a próxima atividade será muito melhor.

Bom, para a próxima aula estudem MPS.BR e CMMI.

Recomendo que tragam bastante material sobre o assunto pois provavelmente será feito uma atividade de pesquisa.

Bons estudos, fiquem com Deus.

terça-feira, 6 de março de 2012

Engenharia de software I

Parabéns a todas as equipes!


Pessoal, parabéns pela apresentação referente à atividade solicitada abaixo.
Fiquei contente com a desenvoltura média da maioria!
Com mais estudo e dedicação vocês se tornarão profissionais de muito sucesso!

Obs. aqueles que por motivos adversos não apresentaram a mesma desenvoltura da maioria, estudem e dediquem-se para fazer a diferença nas próximas atividades.

Atenciosamente,
Marcos Morais.

  Atividade - Modelos de Processo adaptados:
  1. Incremental MARLA
  2. Espiral FELIPE MEIRA
  3. RUP ED
  4. Metodologias Ágeis - BRUNO
Atenção: 
apresentação expositiva com slide.
entregar pesquisa, 
no e-mail divulgado em aula até a data de apresentação, sobre os quatro modelos acima, bem como o material usado para a apresentação (slide, vídeo, etc). 

VALE ATÉ
01 PONTO NA AVALIAÇÃO EM GRUPO DA I UNIDADE

 Obs. Terminar antes ou depois do tempo estipulado
(25 minutos) pode perder pontos!
A ordem das apresentações será definida em aula mediante sorteio.

DATA DA APRESENTAÇÃO: 05/03/2012

sábado, 3 de março de 2012

Analise e Modelagem de Sistemas I






Entendendo o Diagrama de Casos de Uso

Caros, no intuito de reforçar o conteúdo abordado em aula, segue esclarecimentos para ajuda-los a concluir suas atividades extra-classe.

O diagrama de casos de uso é um diagrama da UML cujo objetivo é representar um requisito do sistema que será automatizado. Considere como requisito uma necessidade do sistema.


Simbologia de um caso de uso (requisito que será automatizado): 


Usamos atores para representar as entidades que interagem com o sistema. Podem ser usuários, máquinas, sensores, etc… Um ator representa um papel no sistema, mas um papel pode ser representando por vários atores.


Simbologia de um ator:


Exemplo de um diagrama de casos de uso (sistema bancário):



O ator cliente executará os casos de uso “realizar saque” e “consultar saldo”, enquanto o gerente poderá interagir com os casos de uso “abrir conta” e “vender seguro”.






Relacionamentos entre casos de uso

Os casos de usos podem se relacionar de duas formas:

Quando um caso de uso “A” inclui (include) outro caso de uso “B”. Isto implica que ao executar o caso de uso “A” executa-se também o caso de uso “B”.


Quando um caso de uso “A” tem um relacionamento do tipo extends com outro caso de uso “B”. Implica que ao executar o caso de uso “A” não necessariamente “B” será executado.








Relacionamento entre Atores

O ator pode "herdar" as funcionalidades (casos de uso) de outro ator.





Caso de uso especialização

Os diagramas de casos de uso podem ser simplificados por meio da herança entre atores. Neste caso, mostra-se um caso de uso comum aos atores específicos, que se comunicam apenas com o ator genérico. Neste exemplo, tanto o “Gerente de Compras” quando o “Gerente de Vendas” podem executar o caso de uso “Emissão de relatórios”, porque eles são herdeiros (especializações) de “Gerente”.





Para saber mais, não esqueçam de estudar também pelos livros recomendados abaixo bem como visitar a área com material de estudo, clicando aqui.


Por hoje é só pessoal. Até mais e boa sorte!!

sexta-feira, 2 de março de 2012

Analise e Modelagem de Sistemas I


Caros, segue para download o arquivo que contém um exemplo simples de documentação de software com o conteúdo abaixo:


5 PROJETO
   5.1 LEVANTAMENTO DAS NECESSIDADES
   5.2 ANÁLISE
   5.3 PLANEJAMENTO
      5.3.1    Tecnologias Envolvidas
      5.3.2    Diagrama de Entidade e Relacionamento
      5.3.3    Arquitetura do Software
      5.3.4    Caracterização da interface
   5.4 CODIFICAÇÃO
   5.5 INSTALAÇÃO E TESTE





quinta-feira, 1 de março de 2012

Trabalho Interdisciplinar Dirigido I



Atividade:


  1. Na próxima aula (02-03-2012), trazer o nome das equipes e a proposta de cada equipe.
    Cada proposta apresentada deve virar um projeto (maquete, software, etc.) para apresentar a comunidade acadêmica em local a definir. 
  2. O professor vai discutir com cada equipe a proposta escolhida.
    Cada etapa deverá ser apresentado um relatório pelo líder da equipe sobre o desensenvolvimento da etapa, indicando a participação de cada membro.

    Outros detalhes e esclarecimentos serão discutidos em aula. Lembre-se: cada etapa solicitada, junto com o projeto prático e escrito construído será usado para compor as avaliações da disciplina.

Material de estudo


Caros, segue para download os arquivos e outros materiais usados na confecção das aulas.

Atenção: estudem pelos livros indicados na ementa acrescentando a esse estudo as abordagens em sala de aula e os materiais indicados pelo professor.

Qualquer dúvida entrem contato.
  1. Analise e Modelagem I
  2. Analise e Modelagem II
  3. Engenharia de Software I
  4. Engenharia de Software II
  5. Introdução a Sistemas de Informação
  6. Trabalho Interdisciplinar Dirigido I

Engenharia de Software II


Engenharia de Software II - Avaliação em Grupo I Unidade

Cada equipe deve abordar um modelo para apresentação expositiva com slide, abordando todos os aspectos de cada modelo, apontando vantagens e desvantagens. Deve ser feito comparações com outros modelos. Tempo médio para cada apresentação: 20 minutos.

Detalhe: todos os membros serão avaliados individualmente no dia da apresentação, levando em conta domínio do conteúdo apresentado.

1. Modelo cascata.
2. Modelo interativo e incrementais.
3. Modelos evolutivos de processo.
4. Modelos especializados de processo.
5. Modelos de Processo unificado.

Além da apresentação, deve ser produzido  material impresso referente a todos os modelos e suas respectivas abordagens. Será sorteado na hora o assunto a ser apresentado. Portanto, todas as equipes devem estar preparadas na próxima aula para à apresentação.

Entrega impressa e eletrônica
1. Impressa: ao professor no dia da apresentação
2. Eletrônica no e-mail do professor antes da data de apresentação: marcosmoraisdesousa@gmail.com

Abaixo, a relação de integrantes por equipe.

1-Modelo cascata
Marcos Almeida, Eric Miranda, Diego Santos,

2-Modelo interativo e incrementais 
Jose Roberto, Aloísio Alves, Fábio Nogueira, Charles  Barreto

3-Modelos evolutivos de processo
Edson, Richard

4-Modelos especializados de processo
Danila Araujo, David Jr, Felipe Cajado

5-Modelos de Processo unificado
Jéssica Cerqueira, Caio Lucas, Rodrigo Cardoso