Blog

CAPITULO ATRIBUTO 5 CARDINALIDADE DE DADOS 6 CAPITULO 2. 7- Caso de uso biblioteca 2011 unopar Premium gytuliomiranda Maq OS, 2012 II pages SUMÁRIO CAPITULO 1 — INTRODUÇÃO 3 DESENVOLVIMENTO 4 CAPITULO MODELO CONCEITUAL CAPITULO MODELO FISICO CAPITULO 2. 1- CASO DE USO 4 CAPITULO 2. 2 CAPITULO 2. 3– RELACIONAMENTO 5 5 -ENTIDADE MODELO LÓGICO documentação de Caso de Uso. Caso de uso: Controlar Matrícula Descrição: Fazer cadastro de usuário na blblioteca Funcionário – usuario Ator: Cenário principal 12 13 14 15 16 18 19 110 112 113 114 115 Funcionário solicita cadastro de controle de usuário

Sistema exibe o controle de usuario Funcionário solicita escolhe a opção de inclusão I Sistema atribui código de usuário I Funcionário informa CPF do usuário ISistema valida CPF digitado I Funcionário informa os demais dados I Sistema recupera tipo de acesso I Sistema solicita tipo de acesso Sistema recupera gênero Funcionário seleciona a gênero ISistema recupera supervisor Funcionário seleciona supervisor I Sistema verifica se atributos foram digitados Sistema atribui data do sistema PAGF70F11 Cenário Alternativo 3 13. 1 13. 2 13. 3 13. 4 13. 5 13. 13. 7 13. 8 13. 9 13. 10 3. 8) I Funcionário não escolhe a opção de inclusão I Funcionário digita CPF usuario Sistema recupera dados do usuario Sistema permite alterar Funcionário escolhe opção de alterar I Funcionário informa dados a serem alterados I Funcionário confirma alteração Sistema atualiza os dados Sistema emite mensagem de confirmando alteração Sistema encerra uso case (sistema volta pra o passo Cenário Alternativo 6 16. 1 16. 2 ‘Sistema verifica que o CPF nao é válido ISistema permite nova digitação Cenário Alternativo 14 114. I Sistema verifica os atributos não foram preenchidos | 14. 2 ISistema emite mensagem, informando que os atributos não foram preenchidos 14. 3 I Sistema permite informar os dados não preenchidos PAGF30F11 entidade possui propriedades ou características que as tornam comuns umas com as outras e fazem com que fiquem agrupadas em conjuntos de entidades semelhantes. 2. 3 RELACIONAMENTO É um conjunto de associações entre os elementos que também têm relevância quando associados entre si, e que pode ser encontrada numa descrição textual na língua portuguesa geralmente como verbos. . 4 A RIBCJTO É a característica ou propriedade, ou ainda o próprio dado elevante que se quer manter de uma entidade ou até de um relacionamento. Toda entidade possui propriedades ou qualidades que são descritas por atributos e valores, que podem ser associadas a cada ocorrência de uma entidade ou relacionamento. 2. 5 CARDINALIDADE A cardinalidade é um conceito importante para ajudar a definir o relacionamento, ela define o número de ocorrências em um relacionamento. Para determinar a cardinalidade, deve-se fazer a pergunta relativa ao relacionamento em ambas as dlreçbes.

Um departamento possui quantos empregados? no mínimo 1 e no máximo N. Um empregado está alocado em quantos departamentos? o minimo em 1 e no máximo em 1 Somando-se as cardinalidades, definimos o resultado final do relacionamento, ou seja, I:N 2. 6 MODELO CONCEITUAL DE DADOS O modelo conceitual concentra-se no mais alto nível de abstração e não leva em conta o banco de dados em si, mas a forma como as estruturas serão criadas para armazenar os dados. A modelagem conceitual é a forma mais natural dos fatos e estão mais próximas da realidade do ambiente do cliente.

No modelo conceitual o client nvolvido a fim de obter o PAGFd0F11 limitações e implementa recursos como adequação de padrão e nomenclatura. Define as chaves primárias e estrangeiras. deve ser criado levando em conta os exemplos de modelagem de dados criados no modelo conceitual. 2. 8 MODELO FÍSICO DE DADOS No modelo físico fazemos a modelagem física do modelo de banco de dados. Leva-se em conta as limitações impostas pelo SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem de dados produzidos no item anterior, modelo lógico. . 9 MODELAGEM AGIL. Modelagem Ágil (AM) é uma metodologia baseada na prática pra modelagem efetiva de sistemas baseados em software. A metodologia AM é uma coleção de praticas, uiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia. AM não é um processo prescrito, ela não define procedimentos detalhados de como criar um dado tipo de modelo, ao invés ela provê conselhos de como ser efetivo como modelador. Pense em AM como uma arte, não como uma ciência.

EXEMPLOS XP A Extreme Programming (XP) é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Dentre as principais diferenças da XP em relação às outras metodologias stão: feedback constante, abordagem incremental e a comunicação entre as pessoas é encorajada. O primeiro projeto a usar XP foi o C3, da Chrysler que após anos de fracasso utilizando metodologias tradiclonals, com o uso da XP o projeto ficou pronto em pouco mais de um ano.

SCRUM O foco dessa metodolo ia é encontrar uma forma de trabalho dos membros da roduzir o software de como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. O resultado do processo deve ser um oftware que é realmente útil para o cliente. A metodologia é baseada em princípios semelhantes aos da XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas para promover visibilidade para o desenvolvimento.

No entanto, as dimensões em SCRUM diferem de XP. A SCRIJM divide o desenvolvimento em iterações (sprints) de trinta dias. Equipes pequenas, de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de funcionalidades (requisitos) definidas no início de cada sprint. A equipe é responsável pelo desenvolvimento desta funcionalidade. Na SCRUM existem reuniões de acompanhamento diárias.

Nessas reuniões, que são preferencialmente de curta duração (aproximadamente quinze minutos), são discutidos pontos como o que foi feito desde a última reunião e o que precisa ser feito até a próxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) são identificados e resolvidos. O ciclo de vida da SCRUM é baseado em três fases principais, divididas em subfases: 1) Pré-planejamento (Pre-game phase): os requisitos são escritos em um documento chamado backlog. Posteriormente eles são priorizados e são feitas estimativas de esforço para o desenvolvimento de cada requisito.

O planejamento inclui também, entre outras atividades, a definição da equipe de desenvolvimento, as ferramentas a serem usados, os possíveis riscos do projeto e as necessidades de treinamento. Finalmente é proposta uma arquitetura de desenvolvimento. Eventuais alterações nos requisitos descritos no backlog são identificadas, assim como seus possíveis riscos. 2) Desenvolvime no backlog são identificadas, assim como seus possíveis riscos. ) Desenvolvimento (game phase): as muitas variáveis técnicas e do ambiente identificadas previamente são observadas e controladas durante o desenvolvimento.

Ao invés de considerar essas variáveis apenas no inicio do projeto, como no caso das metodologias tradicionais, na SCRUM o controle é feito continuamente, o que aumenta a flexibilidade para acompanhar as mudanças. Nesta fase o software é desenvolvido em ciclos (sprints) em que novas funcionalidades são adicionadas. Cada um desses ciclos é desenvolvido de forma tradicional, ou seja, primeiramente faz-se a análise, em seguida o projeto, mplementação e testes. Cada um desses ciclos é planejado para durar de uma semana a um mês. ) Pós-planejamento (post-game phase): após a fase de desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são feitas as etapas de integração, testes finais e documentação. MSF Agile A Microsoft Solutions Framework surgiu em 1994 como um conjunto de boas prátlcas compiladas pela Microsoft a partir de sua experiência na produção de software e em serviços de consultoria. Desde então, o MSF evoluiu, tornando- e um framework flexível para nortear o desenvolvimento de projetos de software.

Essa evolução também teve o intuito de acompanhar tendências bem sucedidas no meio da engenharia de softv,’are, como a capacidade de responder à necessidade de mudanças rapidamente. O MSF 4. 0 será nosso objeto de estudo e suas principais características serão avaliadas. MSF Agile Software Development 4. 0 por mais semelhanças que um projeto possa ter em relação a outros, cada projeto de software é único, devido a uma série de fatores que incluem desde o tipo de aplicação a ser construída, necessida e cada cliente e até construída, necessidades específicas de cada cliente e até restrições de cronograma e recursos.

Já existe desde o MSF 3. 0, a consciência por parte de seus criadores de que é impossível definir um únlco processo de desenvolvimento de software que seja adaptável a qualquer situação. Foi devido a isso que OMSF 4. 0 foi lançado em duas versões diferentes, uma que aborda processos ágeis e outra que aborda processos tradicionais. O MSF 4. 0 sustenta os seguintes elementos básicos: Princípios Fundamentais, Modelo de Processo, Modelo de Equipe e Disciplinas. 2. 0 MODELAGEM EVOLUCIONÁRIA Este modelo busca o desenvolvimento de software evoluindo a partir de protótipo inicial.

Todos os conceitos e idéias vão sendo materializado em requisitos a medida que o protótipo evolui, até atingir o produto idealizado. O objetivo é trabalhar com o Cliente em toda a fase do desenvolvimento, a partir das especificações iniciais. Entretanto os requisitos devem ser bem compreendidos. O modelo evolucionário pode trazer diversas vantagens, tais como antecipar o produto final para avaliação do Cliente, manter uma comunicação entre os desenvolvedores e usuários ara solucionar problemas técnicos e antecipar o treinamento dos usuários.

Espiral Este modelo foi desenvolvido para abranger as melhores caracteristicas tanto do ciclo de vida clássico como da prototipaçãc, acrescentando, ao mesmo tempo, um novo elemento, a análise de riscos que falta a esses paradigmas. O modelo define quatro importantes atividades representadas por quatro quadrantes: 1 . Planejamento: determinação dos objetivos, alternativas e restrições. 2. Análise de riscos: anális as e identificação/ cliente: avaliação dos resultados da engenharia.

Ele usa uma abordagem “evolucionária” à engenharia de oftware, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipação como um mecanismo de redução de riscos, mas, o que é mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipaçao em qualquer etapa da evolução do produto. Ele mantém a abordagem de passos sistemáticos sugerida pelo ciclo de vida clássico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real.

O modelo espiral exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e, se adequadamente plicado, deve reduzir os riscos antes que eles se tornem problemáticos. O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as características positivas da gerência (documento associado às fases do ciclo) do modelo de cascata com as fases sobrepostas encontradas no modelo incremental e, também. com as versões anteriores de um sistema do modelo de prototipação.

O modelo em espiral parte do princípio de que a forma do desenvolvimento de software não pode ser completamente determinada de antemão. A prototipação é vista como um meio de redução de iscos, a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo caracteriza-se como um gerador de modelo de processo. Cada ciclo do modelo em espiral possui quatro atividades principais: elaborar objetivos, restrições e alternativas para entidades de softw’are, avaliar alternativas com relação aos objetivos e restrições, e identificar as principais fontes de riscos. ?? Elaborar a definição das entidades de software em um projeto. • Planejar o próximo ciclo. Abortar um projeto se ele apresentar um alto fator de Incremental. Combina elementos do modelo casca PAGF40F11 se ele apresentar um alto fator de Incremental. Combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental é interativo igual à prototipagem, mais diferente a prototipagem o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado.

Esse modelo é muito útil quando a empresa nao possui mao de obra disponível no momento para uma implementação completa, dentro do prazo estipulado. Desenvolvimento baseado em componentes Desenvolvimento baseado em componentes ou omponent-based development (CBD) também é conhecido como component-based software engineering (CBSE) ou simplesmente componente de software, não define o que é um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientação a objetos baseando-se em uma classe como código reutilizável, ou seja, o componente.

Em orientação a objetos uma classe encapsula dados e algoritmos e este último também pode ser usado para manipular os dados. Caracteriza-se esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criação de oftware. Através desta abordagem uma biblioteca de classes é construída com as classes identificadas no desenvolvimento do software e a partir de então toda iteração da espiral devera verificar o conteúdo da biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas na biblioteca para posterior reuso.

SWEBOK Engenharia de software possui vasto material e vánas técnicas para sucesso de software, então o IEEE montou um comitê que se reuniram e montaram um guia chamado SWEBOK que desmembra a engenharia de software em dez áreas de conhecimento que são: • Requisitos de Software,