apostila sobre uml

CoppolaUnified Modeling Language

Unified Modeling Language

CoppolaUnified Modeling Language Modelagem de Dados

Anlise Estruturada x Anlise Orientada a Objetos

Linguagem de Modelagem UnificadaSumrio:


CoppolaUnified Modeling LanguageBIBLIOGRAFIAUML Uma abordagem Prtica * Desenvolvendo software com UML Gilleanes T.A. Guedes Ernani Medeiros, Novatec, 2004 Pearson, 2004 * UML prtico e DescomplicadoUML a Bblia Alexandre Veloso de Matos Tom Penderrica, 2002 Editora CAMPUS, 2004* The complete guide to the UML guia do UsurioUnified process from the original Grady Booch, Rumbaugh, Jacobsondesigners(BOOCH, JACOBSON, Editora Campus, 2006 RUMBAUGH, 1999)

UML e C++ Modelagem e Projetos Baseaos em objetos Guia prtico de Desenv.O. Objeto Rumbaugh, Blaha, Premerlani, Eddy Richard C. LeeLorensen Makron Books, 2002Campus, 1994


CoppolaUnified Modeling LanguageBIBLIOGRAFIAREQ370 Essential of Rational RequisiteProIBM, june 2003

REQ480 Mastering Requirements Management With Use CaseIBM, May 2003

DEV396 Essentials of Rational Software ArchitectureIBM, January 2005

Projeto de Banco de DadosFelipe Machado & Mauricio Abreurica, 1996

Banco de Dados para Web do planejamento ImplementaoLuciano Carlos da Slvarica, 2001


CoppolaUnified Modeling LanguageJustiticativa

Temos observado ao longo dos nossos anos de experincia no Gerenciamento de Desenvolvimento de Softwares(GDS), que existe uma grande dificuldade dos analistas e programadores (Equipe Tcnica) em entederem alguns conceitos e consequentemente a dificuldade em aplic-los no Desenvolvimento de um projeto de software, trazendo como consequncia direta, problemas na especificao, modelagem e documentao de um sistema(software).



Conceitos

prioritriosEstaremos fundamentando, as diferenas entre uma informao e dado, a importncia dos requisitos, suas categorias, Caractersticas e sua respectiva anlise, abordando desde o levantamento, modelagem, especificao e validao. Modelagem DeDadosLinguagem de Modelagem UnificadaUML

Anlise EstruturadaXAnlise Orientadaa ObjetosA deciso:

U M L


CoppolaUnified Modeling LanguageConceitos prioritrios

Informao: Quando acrescentamos algo ao conhecimento da realidade a ser analisada, permitindo a interpretao pelo ser humano. Exemplo: A dosagem de um determinado remdio Dado: uma representao, um registro da informao, um elemento inserido no computador para ser processado, algo, manipulado pelo ser humano, tais como, documentos de texto, imagens ou som. Exemplo: A receita mdica



Sistemas: Gericamente descrevendo, identificam todos os componentes de hardware e software de um nico usurio ou de uma rede. Tambm pode referir-se a um sistema operacional ou a um aplicativo qualquer. (Fialho Jr., 2002)



Sistema de Informao: Conjunto de componentes inter-relacionados que coletam (ou recuperam), processam, armazenam e distribuem informaes destinadas a apoiar a tomada de decises, a coordenao e o controle de uma organizao. Alm de auxiliar, gerentes e trabalhadores a analisar problemas, visualizar assuntos complexos e criar novos produtos. (Laundon & Laundon, 2007)



Software: Conjunto de programas, documentao e procedimentos operacionais com os quais pode-se fazer com que os computadores e outros dispositivos eletrnicos sejam teis aos homens. Sendo que os programas so conjuntos de instrues arranjadas de forma que possam ser entendidas e executadas por um computador



Requisitos:Uma condio ou capacidade que o sistema deve estar de acordo (RUP)Uma capacidade do software necessria ao usurio para resolver um problema ou atingir um objetivo aquilo que o usurio/cliente espera do sistemaObjetivos ou restries estabelecidas por clientes e usurios do sistema que definem as diversas propriedades do sistema Condies que devem atender as necessidades ou restries da organizao ou de outros componentes do sistema


CoppolaUnified Modeling Languageref - IEEE 830Qualidades de um Requisito de SoftwareCorreto

Completo

Consistente

Unambguo

Verificvel

Priorizavel

Modificvel

Rastrevel

Ref. IEEE 830

Unified Modeling Language*How can we tell if we have a good Software Requirement Specification? RUP and IEEE have listed the following qualities of an SRS.Correct Is every requirement in the SRS one that the software should meet?

Complete Does the SRS include all significant requirements, whether related to functionality, performance design constraints, attributes, or external interfaces? Have the expected ranges of input values in all possible scenarios been identified and addressed? Have responses been included to both valid and invalid input values? Do all figures, tables, and diagrams include full labels and references and definitions of all terms and units of measure? Have all TBDs (to be determined) been resolved or addressed?

Consistent Does this SRS agree with the Vision document, the use-case model and the Supplementary Specifications? Does it agree with any other higher-level specifications? Is it internally consistent, with no subset of individual requirements described which are in conflict?

Unambiguous Does each requirement have one, and only one, interpretation?

Ability to Rank Requirements Has each requirement been tagged with an identifier to indicate either the importance or stability of that particular requirement? Have other significant attributes for properly determining priority been identified?

Verifiable Is every requirement stated in the SRS verifiable? Is there some finite cost-effective process with which a person or machine can check that the software product meets the requirement?

Modifiable Are the structure and style of the SRS such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style? Has redundancy been identified, minimized, and cross-referenced?

Traceable Does each requirement have a clear identifier? Is the origin of each requirement clear? Is backward traceability maintained by explicitly referencing earlier artifacts? Is a reasonable amount of forward traceability maintained to artifacts spawned by the SRS?

Briefly review this list that is continued from the previous slide. These are the qualities that should be included in an SRS. Use the questions in the student notes to illustrate the kinds of issues that people should think about when writing good requirements specifications.These qualities of good specifications apply whether you are using a traditional approach or a use-case approach.

CoppolaUnified Modeling LanguageRequisitos Existem em Diversos NveisLevantamento de RequisitosAnalise de RequisitosImplementao do Requisitos

Unified Modeling Language*

See student notes.

CoppolaUnified Modeling LanguageAdapted from Alan DavisO Que NO Faz Parte de um Requisito?Design como o software atender aos requisitos

Verificao como voc sabe que o requisito foi atendido

Dados do Projeto cronogramas, controles, etc.

Unified Modeling Language*The Design Model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The Design Model is used as essential input to activities in implementation and test. The Design Model could be included in the SRS for a very small system, but the SRS and the Design Model are usually separate documents because they have different authors and audiences.The Test Model is a collection of test cases and test procedures and their relationships. A test case can be implemented by one or more test procedures, and a test procedure may implement (the whole or parts of) one or more test cases. The Test Model and the SRS are usually separate documents because they have different authors and audiences. However, some customers, such as the U.S. Military, may require that the SRS include the Test Model.A Test Case is a set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. A Test Procedure is a set of detailed instructions for the set-up, execution, and evaluation of results for a given test case (or set of test cases).The Software Development Plan is a comprehensive, composite artifact, which gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and maintained throughout the project. Emphasize: The Design Model could be included in the SRS for a very small system, but the SRS and the Design Model are usually separate documents because they have different authors and audiences. The same is true for test documents and management documents.

CoppolaUnified Modeling LanguageEntendendo as necessidades


CoppolaUnified Modeling LanguageTcnicas Para Levantar Necessidades dos EnvolvidosWorkshop de RequisitosBrainstorming e Reduo de IdiasWorkshops de Casos de UsoStoryboardsEntrevistasQuestionriosRole PlayingProttiposReviso de Especificaes de Requisitos do Cliente


What follows is a crash course in elicitation techniques. We have selected the techniques on our list because of their usefulness in our experience. We briefly discuss each topic in turn.Beyond the techniques we discuss there are many other techniques such as:Production softwareTask analysis

Most techniques discussed in this module are generally useful for eliciting information. We discuss them from the perspective of eliciting needs and features, but the same techniques can be used for all types of requirements (needs, features, software requirements), and at many levels of detail.

CoppolaUnified Modeling LanguageTcnicas Para Levantar Necessidades dos EnvolvidosPorque modelar software???

Muitos profissionais desenvolvedores web, podem afirmar que conseguem determinar todas as necessidades de um sistema de informao de cabea e que sempre trabalharam assim, um hbito comum.Pensar antes de fazer sempre uma boa opo e modelar antes de codificar uma tima coisa a fazer tambm.Modelar particularmente importante quando consideramos preocupante as aes simultneas, que no acontecem facilmente j que sua cabea est focada no cdigo.





Conceitos

prioritriosModelagem DeDadosLinguagem de Modelagem UnificadaUML


U M L



Conceitos



U M L

A modelagem de dados (ou de informaes) est baseada no princpio de que, comprovadamente, os dados so estveis no decorrer da vida de uma corporao ou instituio, no tendo volatilidade dependente de fatores externos. J os procedimentos possuem esta caracteristicas de volatilidade.


CoppolaUnified Modeling LanguageMODELAGEM DE DADOSModelagem de dados o ato de definir estruturas capazes de representar os dados relevantes para um sistema de informao. Existem vrios conceitos, regras e consequentemente tcnicas que podem auxiliar um bom modelo de dados.O processo de modelagem pode, e deve na maioria das situaes, obedecer um conjunto de tcnicas e boas prticas para representar, com a maior preciso possvel, a realidade a ser modelada bem como tornar possvel a evoluo do modelo de dados frente a alteraes sofridas nessa realidade.

(Gonalves C. Mauri, 2006).A modelagem est focada em construir bases de dados que atendam s reais necessidades de informao de um determinado ambiente, de forma a melhor aproveitar os recursos de um SGBD.




CoppolaUnified Modeling LanguageA construo de base de dados pode ser dividida em trs fases bem distintas:

Modelagem Conceitual - O analista, deve se concentrar na observao dos fatos que ocorrem na realidade. - Artefatos que registram estes fatos s devem ser utilizados como apoio ao entendimento.Projeto Lgico- Tem seu incio a partir do modelo Conceitual- Decreve as estruturas que estaro contidas no banco de dados.Projeto Fsico- Tem seu inicio a partir do Modelo Lgico- nfse na implementao de consultas (SQL Data Definition Language-DDL)MODELAGEM DE DADOS




CoppolaUnified Modeling LanguageModelagem Conceitual-No retrata os apectos ligados abordagem do banco de dados que ser utilizado e to pouco com suas forma de acesso e estruturas fsicas.- Deve representar a realidade do ambiente do problema- constitudo de uma viso global, procurando relatar os principais requisitos de dados do domnio e seus respectivos relacionamentos.- MACRODEFINIO MODELAGEM DE DADOS

MUNDO REAL




CoppolaUnified Modeling LanguageModelo(Projeto) Lgico-No deve considerar nenhuma caracterstica especfica de SGBD-Maior nfase na eficincia de armazenamento dos dados, porm, evitando muitas tabelas (normalizao), junes e tabelas sub-utilizadas.MODELAGEM DE DADOS

CLIENTEFAZPEDIDOPOSSUIGERAFATURANOTA




CoppolaUnified Modeling Language3. Modelo (Projeto) Fsico- Inicia a partir do Modelo Lgico e descreve as estruturas fsicas de armazenamento de dados- Modelo projetado, levando em considerao os requisitos de processamento e uso mais econmico dos recursos computacionais.- Detalha o estudo dos mtodos de acesso do SGBD (ndices) MODELAGEM DE DADOSACESSOSINDICESTAMANHO DO CAMPOTIPO DE CAMPO




CoppolaUnified Modeling LanguageNosso objetivo primordial entendermos o negcio, para o qual projetaremos um sistema, atravs de seus dados

Peter Chen(1976): Quando formulou a proposta do modelo Entidade-Relacionamento, baseou-se no na viso de um sistema de aplicao como princpio e sim na compreenso da realidade em que se situava o problema.Como iremos projetar um sistema se no entendermos o negcio para o qual ser realizado? (Machado & Abreu, 1996) MODELAGEM DE DADOS




CoppolaUnified Modeling LanguageChen dedicou-se a destacar a importncia de reconhecer os objetos que compem este negcio, a estes objetos Chen classificou em dois grupos:

Entidades e RelacionamentosEntidades

Entidade um agrupamento lgico de informaes inter-relacionadas necessrias para a execuo das atividades do sistema. Uma entidade normalmente representa um objeto do mundo real ou, quando no , contm informaes relevantes s operaes da empresa.MODELAGEM DE DADOS




CoppolaUnified Modeling LanguageExemplos de Entidades

Documentos Ordem de Compra, pedidos, nota fiscal Local Almoxarifado e departamentoMatria Produto e peaAs entidades podem ser classificadas em dois tipos

Fundamental Contm dados bsicos que so resultados ou alimentadores das operaes da empresaAssociativa formada pelo Relacionamento de duas Entidades sempre que estas se relacionarem mais de uma vez. Exemplo: Aluno x matria, CD x Autor, pedido x produto etc.MODELAGEM DE DADOS




CoppolaUnified Modeling LanguageAtributos

Os atributos so as informaes bsicas que qualificam uma entidade e descrevem seus elementos ou caractersticas. Quando transpostos ao modelo fsico (ao banco de dados), chamamos os atributos de campos ou colunas.Exemplos de atributos para as entidades:

Entidade pessoa: nome, endereo, documento, data de nascimento, telefone e e-mailEntidade Nota Fiscal: srie, nmero, data de emisso e clienteMODELAGEM DE DADOS




CoppolaUnified Modeling LanguageIntroduo ao relacionamento

Sempre que duas entidades apresentarem interdependncia (por exemplo, autor da msica ou msica do CD), indica-se um relacionamento entre elas.Regra:

Cada entidade 1 deve ter relacionamento uma ou mais entidade 2 Ou ou Pode ter uma nica MODELAGEM DE DADOS




CoppolaUnified Modeling LanguageMODELAGEM DE DADOS





Conceitos


Anlise EstruturadaXAnlise OrientadaA ObjetosA deciso:

U M L

O objetivo disto fornecer multiplas vises do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos, procurando atingir a completitude da modelagem, permitindo que cada diagrama complemente os outros, como se o sistema fosse modelado em camadas (Uma tica para cada diagrama).


CoppolaUnified Modeling LanguageUML


CoppolaUnified Modeling LanguageUML = Unified Modeling Language ou (Linguagem de Modelagem Unificada): um conjunto de ferramentas (desenhos) que permitiro representar o modelo de um sistema qualquer, porm, por meio do Paradigma de Orientao a objetos.


CoppolaUnified Modeling LanguageO que a UML ?A UML uma linguagem padro para visualizar, especificar, construir e documentar os artefatos de um sistema intensamente baseado em softwareA UML combina:Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento)Modelagem de Negcios (Fluxo de trabalhos)Modelagem de ObjetosModelagem de ComponentesPode ser usada com todos os processos, durante todo o ciclo de desenvolvimento e com diferentes tecnologias de implementao


CoppolaUnified Modeling LanguageU M LA UML vai alm de uma simples padronizao em busca de uma notao unificada, pois incorpora conceitos novos no encontrados em outros mtodos orientados a objetos. A UML auxilia na definio das caractersticas do software, tais como seus requisitos, seu comportamento, sua estrutura lgica, a dinmica de seus processos e at as necessidades fsicas em relao sobre o qual o sistema dever ser implantado.Existem atualmente 13 diagramas da UML, porm, segundo Booch, os diagramas mais utilizados so diagramas de classe (dependendo do seu domnio), diagramas e casos de uso e diagramas de sequncia ou de estado. Os diagramas da UML 2.0 (Diagrama de Classes, Instalao, Objetos, Pacotes, Estrutura Composta, Componentes, Casos de Uso, Atividades, Interao, Estados, Temporizao, Sequncia, Viso Geral Interao e Comunicao).


CoppolaUnified Modeling LanguageU M LA UML o brao direito do RUP (Rational Unified Process), mas isso no significa que ela seja dependente do RUP, na verdade ocorre o contrrio, pois a UML totalmente independente de processo ou modelo, podendo ser utilizada para diversas finalidades. O RUP apenas utiliza intensivamente os recursos da UML para a gerao de seus artefatos referentes a um software.A UML atualmente composta por treze diagramas onde cada um possui sua prpria semntica, sendo que, cada diagrama utilizado conforme as fases de um projeto de software. Isso significa que, em uma fase inicial (fase de Concepo do RUP, por exemplo) de projeto utilizado um determinado diagrama que ao mesmo tempo se torna requisito fundamental para o uso do prximo diagrama e assim sucessivamente.



Contribuies para a UMLJr. Brandi, Vitor,. 2007


CoppolaUnified Modeling LanguageUML2Criao da UMLMtodo de BoochOMT2000/2003 (menores revises)Final de 1996(maiores revises)


CoppolaUnified Modeling LanguageDesenvolvimento de diferentes aplicaesclassesparticionamento de aplicaesobjetos de negciosrelacionamentosProcessos de negciosobjetoscasos de usosistemas de larga escalacenrioscomponentesMicrosoftActiveX/COMMicrosoftORDBMSOracleCORBAOMG

Jr. Brandi, Vitor,. 2007


CoppolaUnified Modeling LanguageUsos da UMLA UML pode ser utilizada para:Mostrar a periferia de um sistema e suas principais funes usando Casos de Uso e AtoresIlustrar realizaes de Casos de Uso com Diagramas de InteraesRepresentar a estrutura esttica de um sistema usando Diagramas de ClassesModelar o comportamento de objetos com Diagramas de Transies de EstadoRevelar a arquitetura da implementao fsica com Diagramas de Componentes e Distribuio Estender sua funcionalidade com Esteretipos


CoppolaUnified Modeling LanguageViso geral da UMLElementos de ModelagemRelacionamentos Mecanismos de Extensibilidade Diagrama


CoppolaUnified Modeling LanguageElementos de ModelagemElementos estruturaisclasses, interfaces, colaborao, casos de uso, classes ativas, componentes, nsElementos de comportamentointerao, mquinas de estadoElementos de agrupamentopackage (pacote), subsistemasOutros elementosnotas (comentrios)


CoppolaUnified Modeling LanguageRelacionamentosDependnciaAssociaoGeneralizaoRealizao


CoppolaUnified Modeling LanguageMecanismos de ExtensibilidadeEsteretiposValores marcados (Tagged value)Restries (Constraint)


CoppolaUnified Modeling LanguageDIAGRAMAS DA UMLDiagrama de EstruturaDiagrama de ComportamentoDiagrama de ClassesDiagrama de ObjetosDiagrama de PacotesDiagrama ComponentesDiagrama InstalaoDiagrama Estrutura CompostaDiagrama Casos de Uso Diagrama De InteraoDiagrama De AtividadesDiagrama De EstadosDiagrama ComunicaoDiagramas Viso Geral InteraoDiagramas SequenciaDiagramas Temporizao


CoppolaUnified Modeling LanguageDiagramasUm diagrama uma viso de um modeloApresentado a partir de um aspecto particularProv uma representao parcial do sistema semanticamente consistente com outras vises

Existem treze diagramas padro na UML, de acordo com a OMG (www.omg.com)


CoppolaUnified Modeling LanguageDiagramas EstruturaisDiagramas de Classes: Permite representar as classes do sistema, suas caractersticas (atributos) e aes (mtodos). Voc consegue expor as relaes existentes entre as classes utilizando o conceito de orientao a objetos, o que uma grande vantagem para os desenvolvedores que utilizam linguagens de programao orientadas a objetos, to comum nos dias de hoje.


CoppolaUnified Modeling LanguageDiagramas EstruturaisDiagramas de Instalao: Descreve a configurao de elementos de suporte ao processamento, componentes de software, processos e objetos existentes nesses elementos, ou seja, ilustra os componentes de hardware e software e sua iterao com outros elementos de suporte ao processamento.


CoppolaUnified Modeling LanguageDiagramas EstruturaisDiagramas de Objetos: uma boa opo para explicar relacionamentos complexos entre classes. Mostra os objetos que foram instanciados das classes. Os nomes dos objetos so sublinhados e todas as instncias so mostradas. Tambm usado como parte dos diagramas de colaborao, onde , mostrada a colaborao dinmica entre os objetos do sistema. O diagrama de objetos fornece uma viso dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento de execuo de um processo. Os diagramas mostram apenas os mtodos e propriedades que retornam os objetos.


CoppolaUnified Modeling LanguageDiagramas EstruturaisDiagramas de Pacotes: Pode ser chamado tambm de Diagrama de Mdulos. Pacote representa um grupo de classes, ou elementos, e dependente de outros pacotes. O Diagrama de pacotes mostra pacotes ou pedaos do sistema e relaes entre pacotes. Ele mais utilizado para ilustrar a arquitetura do projeto mostrando o agrupamento de suas classes. No preciso seguir uma hierarquia, ele pode ser utilizado em qualquer fase do processo de modelagem.


CoppolaUnified Modeling LanguageDiagramas EstruturaisDiagramas de Estrutura Composta: Mostra o relacionamento entre os elementos e especfica as suas funcionalidades.Diagramas de Componentes: Descreve as dependncias entre componentes de softwares, como de cdigo fonte, cdigo binrio e executveis. Destaca a funo de cada mdulo para facilitar a reutilizao e auxilia no processo de engenharia reversa, por meio da organizao dos mdulos do sistema e seus relacionamentos. Ele mostra apenas o que relevante em um subsistema de implementao. Este diagrama representado na forma de tipos e no na forma de instncias.


CoppolaUnified Modeling LanguageCASOS DE USO


CoppolaUnified Modeling LanguageDiagrama de Caso de UsoCaptura a funcionalidade do sistema conforme vista pelos usurios


CoppolaUnified Modeling LanguageDiagramas de Caso de UsoConstrudo nos estgios iniciais do desenvolvimentoPropsitoespecificar o contexto de um sistemacapturar os requisitos de um sistemavalidar a arquitetura do sistemadirecionar a implementao e gerar casos de testeDesenvolvido por analistas e usurios especializados no domnio da aplicao


CoppolaUnified Modeling LanguageCasos de UsoUm caso de uso uma tcnica de modelagem utilizada para: descrever o que um novo sistema deve fazer descrever o que um sistema existente j fazCaractersticas construdo atravs de um processo iterativo envolve desenvolvedores do sistema e os clientes do sistema (ou usurios finais) eventualmente leva a uma especificao comum de requisitos


CoppolaUnified Modeling LanguageCasos de UsoCriado por Ivar Jacobson,1994Primeiramente utilizado na metodologia OOSE/ObjectoryNo exclusividade da UMLDiversas outras metodologias foram adaptadas para utilizar Casos de Uso para representar a especificao funcional do sistema


CoppolaUnified Modeling LanguageComponentes PrincipaisO modelo de casos de uso tem como principais componentes:atores: entidade externa que interage com os casos de usocasos de uso: especifica uma funcionalidade completa do sistemaDiagrama: conjunto de casos de uso que interage com atores


CoppolaUnified Modeling LanguageCaractersticasAs fronteiras do sistema so especificadas pela funcionalidade do sistemaA funcionalidade do sistema representada por uma srie de casos de usoCada caso de uso especifica completamente uma funcionalidadeUm caso de uso sempre deve devolver algum valor para um ator


CoppolaUnified Modeling LanguageCaractersticasO ator uma entidade externa que tem interesse em interagir com o sistemaO sistema deve ser enxergado como uma caixa-preta que prov casos de uso, ou seja,No importante especificar como as funcionalidades sero implementadas, mas sim quais so esta funcionalidades.


CoppolaUnified Modeling LanguagePropsitos dos Casos de UsoDecidir e descrever os requisitos funcionais do sistemaprover uma descrio clara e consistente do que o sistema deve fazerprover a base para a realizao de testes que validam e verificam o sistemaprover facilidades para se rastrear requisitos funcionais dentro das classes e operaes do sistema


CoppolaUnified Modeling LanguageQuem se interessa pelo modelo de casos de uso ?Clientes e usurios finais: pois ele especifica a funcionalidade do sistema de uma forma clara e fcil de entenderDesenvolvedores: pois ele ajuda a entender o que o sistema deve fazerIntegradores e Testadores do sistema: pois eles provm a base para se integrar e testar o sistema


CoppolaUnified Modeling LanguagePara se criar modelos de caso de usoDefinir o sistemaencontrar os atoresencontrar os casos de usodescrever os casos de usodefinir os relacionamentos entre os casos de usovalidar o modelo


CoppolaUnified Modeling LanguageDiagramas de Casos de UsoO modelo de casos de uso consiste em uma srie de diagramas de casos de uso, portanto,diagramas de casos de uso descrevem o modelo de casos de usoo diagrama de casos de uso prov mecanismos para representar os principais componentes do modelo de casos de uso e os eventuais relacionamentos entre estes componentes


CoppolaUnified Modeling LanguageCasos de uso


CoppolaUnified Modeling LanguageAtoresAtor: um papel que um usurio executa em relao ao sistema. Os atores desempenham os casos de uso. Um nico ator pode desempenhar vrios casos de uso; um nico caso de uso pode ter reciprocamente vrios atores desempenhando-o ou participando. Atores podem ser vistos como participantes do caso de uso que obtm valor dos mesmos. Atores podem ser: humanos, outros sistemas, dispositivos externos, etc., que interagem com o sistema. Smbolo:


CoppolaUnified Modeling LanguageIdentificando AtoresAs respostas s seguintes perguntas podem auxiliar a identificar atores:quem utiliza a principal funcionalidade do sistema ?quem vai precisar de suporte do sistema para realizar suas tarefas dirias ?quem precisa manter, administrar e deixar o sistema rodando ?quais dispositivos de hardware o sistema precisa manipular ?com quais outros sistemas o sistema precisa interagir?quem ou o que tem interesse nos resultados produzidos pelo sistema ?


CoppolaUnified Modeling LanguageRelacionamento entre AtoresMesmo externos ao sistema, os atores podem se relacionarno diagrama de casos de uso, o nico relacionamento representado o de generalizaogeneralizaes so representadas quando dois ou mais atores desempenham um papel mais genrico


CoppolaUnified Modeling LanguageRelacionamentos entre AtoresGeneralizao: Um relacionamento de generalizao entre Atores significa que os Atores B e C representam papis que especializam o papel definido pelo Ator A.O relacionamento de generalizao entre atores indica que os atores pertencem a um mesmo grupo semntico de usurios (ou papis) e que compartilham responsabilidades. Os atores especializados herdam todas as caractersticas e links de comunicao do ator da generalizao. Dessa forma, todos os casos de uso que o ator generalizado pode executar podero ser executados tambm pelos atores das especializaes.Ex:


CoppolaUnified Modeling LanguageCasos de UsoOriginado a partir do mtodo do Jacobson. Casos de Uso so utilizados para modelar os requisitos funcionais do sistema. Casos de Uso descrevem as funcionalidades do sistema, conforme esperadas pelos usurios, retratando um dilogo que uma entidade externa, chamada Ator, realiza com o sistema. Um Caso de Uso baseado num cenrio descritivo de como o Ator interage com o sistema. Ele identifica eventos que podem ocorrer e descreve as respostas do sistema para estes eventos.Um Caso de Uso, em ltima instncia, representa um fluxo de eventos completo e com significado, descrevendo uma situao de uso particular do sistema. Smbolo:


CoppolaUnified Modeling LanguageCasos de UsoDefinido como um conjunto de seqncias de aes que um sistema executa que produzem um resultado observvel por um particular atorrelaciona-se com um ou mais atores atravs de associaes associaes so, normalmente, bidirecionais


CoppolaUnified Modeling LanguageCasos de Uso sempre iniciado por um ator (que direta ou indiretamente ordena ao sistema a execuo de um caso de uso)prov sempre um valor (discernvel) para o atorum caso de uso completo incorreto quebrar um caso de uso grande em diversos casos de usos menores, pois no se deve especificar como o caso de uso ser implementadosomente se completa quando produz um valor


CoppolaUnified Modeling LanguageEncontrando casos de usoAs respostas s seguintes perguntas podem auxiliar a encontrar casos de uso:Quais funes o ator requer do sistema ? O que o ator precisa fazer ?O ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informao dentro do sistema ?O ator precisa ser notificado de eventos do sistema ? O ator precisa notificar o sistema sobre algum evento ?O trabalho dirio do ator poderia ser simplificado ou tornado mais eficiente atravs de novas funcionalidade do sistema ?Quais entradas e sada o sistema precisa ?Quais os principais problemas com o atual sistema ?


CoppolaUnified Modeling LanguageDiagrama de Casos de Uso: exemplo 1


CoppolaUnified Modeling LanguageDiagrama de Casos de Uso: exemplo 2

Sistema de Controle de Vendas


CoppolaUnified Modeling LanguageRelacionamentos entre Casos de UsoIncluso: (referenciado como: uses, include ou inclui)Um relacionamento de Incluso do Caso de Uso A para o Caso de Uso B, indica que o comportamento de B estar includo no comportamento de A. Principal objetivo: reutilizaoA associao de incluso ocorre, principalmente, quando h uma parte do comportamento que semelhante em mais de um caso de uso e no se deseja ficar copiando a descrio deste comportamento. Ex:


CoppolaUnified Modeling LanguageRelacionamentos entre Casos de UsoExtenso: (referenciado como: estende ou extend)Um relacionamento de extenso do Caso de Uso B para o Caso de Uso A, indica que o comportamento de A pode ser estendido pelo comportamento especificado em B. O caso de uso de extenso pode acrescentar comportamento ao caso de uso base. Extenso deve ser utilizada quando se est descrevendo uma variao em comportamento normal do caso de uso. um comportamento adicional.Pontos de extenso podem ser declarados no caso de uso base. Ex:


CoppolaUnified Modeling LanguageRelacionamentos entre Casos de UsoGeneralizao: Um relacionamento de generalizao entre um Caso de Uso A e Casos de Uso B e C, indica que o comportamento de A especializado em B e C. Os casos de uso B e C apresentam uma estrutura muito semelhante (fluxos de eventos, regras, etc.), ento, a parte em comum fatorada para um caso de uso de generalizao Os casos de uso especializados B e C podem acrescentar comportamento (passos no fluxo principal, fluxos alternativos adicionais), sobrescrever comportamento ou acrescentar dados de entrada e sada, regras, etc.Ex:


CoppolaUnified Modeling LanguageTestando o sistema atravs dos casos de usoOs casos de uso facilitam a aplicao de dois diferentes tipos de testes:teste de validao: Estamos construindo o produto certo?efetuado assim que se produz um modelo de caso de usoapresenta-se e discute-se os diagramas de caso de uso com os usurios para que eles validem-no e complementem-noteste de verificao: Estamos construindo certo o produto ?efetuado assim que a implementao das primeiras partes do sistemas estiver prontaconfronta-se o comportamento obtido da execuo do sistema com o comportamento esperado (especificado nos diagramas de caso de uso)


CoppolaUnified Modeling LanguagePassos para Elaborar o Modelo de Casos de Uso do SistemaIdentificar os Atores do SistemaIdentificar os Casos de Uso do SistemaIdentificar as Associaes entre Atores e Casos de UsoElaborar o Diagrama de Casos de UsoDividir os casos de uso em pacotes se houver necessidadeDescrever os casos de usoVerificar relacionamentos entre casos de uso: incluso, extenso e generalizao


CoppolaUnified Modeling LanguageDiagrama de AtividadeCaptura comportamento dinmico (orientado por atividades)

PropsitoModelar fluxos de negciosModelar operaes


CoppolaUnified Modeling LanguageDiagrama de Atividades


CoppolaUnified Modeling LanguageIntroduoO diagrama de atividades modela aes e seus resultados. Seu foco est no trabalho executado na implementao de uma operao (mtodo) e as atividades dentro de um caso de uso ou dentro de um objeto.Pode ser considerado uma variante do diagrama de estados, porm com um propsito ligeiramente diferente, que capturar aes e seus resultados em termos de mudanas de estados dos objetos.


CoppolaUnified Modeling LanguageUtilizaoDiagramas de atividades podem ser utilizados para:capturar aes que sero realizadas quando uma operao est em execuo (utilizao mais comum)mostrar como um conjunto de aes relacionadas pode ser executado e como elas afetam os objetos ao redormodelar uma instncia de um caso de uso em termos das aes e das mudanas de estadosmodelar aplicaes que possuem processamento concorrente


CoppolaUnified Modeling LanguageQuando no utilizarNo se deve utilizar diagramas de atividades para:representar como os objetos colaboram (para isto existe o diagrama de seqncia)representar como um objeto se comporta atravs do tempo (para isto existe o diagrama de estados)


CoppolaUnified Modeling LanguageAes e TransiesUma ao executada para produzir um resultado. A implementao de uma operao pode ser descrita como um conjunto de aes relacionadas, que depois sero traduzidas em linhas de cdigo.


CoppolaUnified Modeling LanguageNotao

AtividadeTransioRamificao ou Deciso


CoppolaUnified Modeling LanguageExemplo de diagrama de atividades


CoppolaUnified Modeling LanguageDecisoAs transies em um diagrama de atividades podem conter desvios, condies de guarda e clusulas de envio associadas. Exemplo:


CoppolaUnified Modeling LanguageIteraoO efeito de iterao pode ser obtido com o uso de ramificaes. Por exemplo, conforme mostra o exemplo abaixo, pode-se utilizar estados de ao para inicializar e incrementar um contador e uma ramificao avaliando se a iterao foi concluda.


CoppolaUnified Modeling LanguageExemplo Processo de Desenvolvimento de Software com Iterao


CoppolaUnified Modeling LanguageProcesso: Matricular Alunos


CoppolaUnified Modeling LanguageRaias de Natao (swimlanes):Este recurso muito til, principalmente na modelagem de fluxos de trabalho de processos de negcio. Permite o particionamento das atividades em grupos, onde cada grupo de atividades executado ou desempenhado por um setor, departamento ou papel da organizao. Cada grupo chamado de raia de natao.


CoppolaUnified Modeling LanguageExemplo de Raias


CoppolaUnified Modeling LanguageExemplo 1


CoppolaUnified Modeling LanguageExemplo 2


CoppolaUnified Modeling LanguageExemplo 2(com raias)


CoppolaUnified Modeling LanguageDiagramas de Classe Captura o vocabulrio do sistema


CoppolaUnified Modeling LanguageDiagrama de Classe Construdo e refinado durante todo o processo de desenvolvimentoPropsitonomear e modelar conceitos dentro do sistemaespecificar colaboraesespecificar esquemas lgicos de bancos de dadosDesenvolvido por analistas, projetistas e implementadores


CoppolaUnified Modeling LanguageDiagrama de ObjetosCaptura instncias e ligaes (links)


CoppolaUnified Modeling LanguageDiagrama de ObjetosConstrudo durante as etapas de anlise e projetoPropsitoilustrar a estrutura dos dados e objetosespecificar instantneos do sistemaDesenvolvido por analistas, projetistas e implementadores


CoppolaUnified Modeling LanguageDiagrama de ComponentesCaptura a estrutura fsica da implementao


CoppolaUnified Modeling LanguageDiagrama de ComponentesConstrudo como parte da especificao da arquitetura do sistemaPropsito:organizar o cdigo fontecontruir uma verso executvel da aplicaoespecificar fisicamente os bancos de dadosDesenvolvido por arquitetos e programadores


CoppolaUnified Modeling LanguageDiagrama de distribuio (Deployment)Captura a topologia do hardware do sistema


CoppolaUnified Modeling LanguageConstrudo como parte da especificao da arquitetura do sistemaPropsito:especificar a distribuio dos componentesidentificar gargalos de desempenhoDesenvolvido por arquitetos, engenheiros de rede e engenheiros de sistema

Diagrama de distribuio (Deployment)


CoppolaUnified Modeling LanguageDiagramas de Seqncia Captura comportamento dinmico (orientado por tempo)Propsitomodelar o fluxo de controleilustrar cenrios tpicos


CoppolaUnified Modeling LanguageDiagramas de ColaboraoCaptura comportamento dinmico (orientado por mensagens) Propsitomodelar o fluxo de controleilustrar a coordenao entre estrutura e controle do objeto


CoppolaUnified Modeling LanguageDiagramas de EstadoCaptura comportamento dinmico (orientado por eventos) Propsitomodelar o ciclo de vida do objetomodelar objetos reativos (interfaces, dispositivos etc.)


CoppolaUnified Modeling LanguageDiagrama de AtividadeCaptura comportamento dinmico (orientado por atividades)

PropsitoModelar fluxos de negciosModelar operaes



Conceitos



U M L

Qual a melhor ou pior metodologia? Qual utilizar ou no utilizar?; Certamente no sero questes que responderemos nesse tpico, e sim, as caracteristicas de cada metodologia, fazendo uma comparao de cada mtodo, analisando e proporcionando informaes na conduo de sua aplicabilidade em uma corporao.



Anlise Estruturada X Anlise Orientada a Objetos


CoppolaUnified Modeling LanguageAnlise EstruturadaO mais amplamente usado dos mtodos de modelagem de requisitosModelos que retratam fluxo e o contedo da informao (dados e controle)O sistema dividido em parties funcionais e comportamentais e descrevemos a essncia do que deve ser construdoOs primeiros trabalhos datam do final da dcada de 1960


CoppolaUnified Modeling LanguageDiagrama de fluxo de dadosUm DFD uma tcnica grfica que descreve o fluxo da informao e as transformaes sofridas por estaPode ser utilizado para representar um sistema em qualquer nvel de abstraoNotao simplesNenhuma indicao explicita da seqncia fornecida pelo diagrama


CoppolaUnified Modeling LanguageExemplo de DFD


CoppolaUnified Modeling LanguageExtensesA notao bsica da anlise estruturada sofreu uma ampliao por Ward e Mellor para acomodar exigncias exigidas por sistemas de tempo realAs extenses de Hatley e Pirbhai concentram-se na representao e especificao dos aspectos orientados ao controle de software


CoppolaUnified Modeling LanguageModelagem comportamentalAparece somente nas verses extendidasDiagrama de estados - Representa o comportamento de um sistemaDescreve os estados do sistema e eventos que fazem com que mude de estadoIndica quais as aes executadas como conseqncia de um dado evento


CoppolaUnified Modeling LanguageDicionrio de requisitos uma listagem organizada de todos os elementos de dados que so pertinentes ao sistema, com definies precisas e rigorosas, de forma que tanto o usurio como o analista tenham uma compreenso comum das entradas, das sadas, dos componentes dos depsitos de dados e at mesmo dos clculos intermedirios.


CoppolaUnified Modeling LanguageAnlise Orientada a ObjetosEnxerga o mundo como objetos com estrutura de dados e comportamentosO objetivo desenvolver uma srie de modelos de anlise, satisfazendo um conjunto de requisitos definidos pelo cliente


CoppolaUnified Modeling LanguageConceitos fundamentaisClasse Objetos Herana EncapsulamentoPolimorfismo


CoppolaUnified Modeling LanguageMtodos de anliseUma grande variedade de mtodos de anlise orientada a objetos foram desenvolvidos desde 1988. Porm, todos eles possuem caractersticas comuns entre siRepresentao de classes e hierarquias Criao de modelos de relacionamento de objeto Derivao de modelos de comportamento de objetos


CoppolaUnified Modeling LanguageCaractersticasManutenibilidade Simplificao do mapeamento so mundo realReusabilidade Pelos artifcios de anliseGanhos na produtividadeDireto mapeamento pelas linguagens de programao OO


CoppolaUnified Modeling LanguageAlguns mtodos conhecidosMtodo de Booch Mtodo de Jacobson Mtodo de Rambaugh UML (Unified Modeling Language)Combina as notaes dos mtodos acimaLinguagem consistente para especificao, visualizao, construo e documentaoPadro adotado pela OMG (Object Management Group)


CoppolaUnified Modeling LanguageDiferenas entre as metodologiasA abordagem OO se preocupa primeiramente em identificar os objetos a partir do domnio da aplicao, para depois encaixar os funes ao redor destes objetosos conceitos de OO podem ser aplicados em todo o ciclo de vida do desenvolvimento do sistema. Uma pode ser detalhada a medida que o processo de desenvolvimento evolui


CoppolaUnified Modeling LanguageBenefcios da OOPodem representar melhor o mundo real Modelagem mais perfeita e natural A mesma usada desde a anlise at o projeto e a implementao, de modo que a informao adicionada em uma etapa do desenvolvimento no necessariamente perdida ou traduzida para a etapa do seguinte


CoppolaUnified Modeling LanguageBenefcios OODedicao maior fase de anliseOcorre uma reduo na quantidade de erros com conseqente diminuio do tempo despendido nas etapas de codificao e testeOs modelos espelham a estrutura e o comportamento dos objetos do negcio, diminuindo o abismo existente nas outras abordagens que tratam dados e funes separadas


CoppolaUnified Modeling LanguageBenefcios OOReduo no tempo de manuteno, pois as revises so mais fceis e mais rpidas j que o problema mais bem localizado Favorece a reutilizao Facilidade de extenso. A criao de novos objetos que se comuniquem com os j existentes no obriga o desenvolvedor a conhecer o interior destes ltimos



Conceitos



U M L

Tentaremos demonstrar que a UML uma linguagem que permite argumentar sobre o sistema, ento, certamenteela uma metodologia poderosa em termos de ajuda, considerando abstraes incisivas, tendo a separao apropriada das preocupaes e uma distribuio balanceada de responsabilidades.


CoppolaUnified Modeling LanguageUMLEscolher o modelo certo uma questo de entendimento de qual viso voc est tentando abstrair.Interpretar diagramas como respirar. Posso olhar para um diagrama e rapidamente saber o que est acontecendo.


CoppolaUnified Modeling LanguageUML At o momento no h nenhuma espcie de software complexo que no consigamos modelar na UML.A UML 2.0 trouxe um variedade de elementos para a linguagem, suporte para Model-Driven Development. No futuro, segundo Booch ser simpificado o metamodelo e 20% ser reduzido da UML que se aplica aos 80% dos problemas da modelagem que as pessoas enconram em uso real.



F I M MODELAGEM DE DADOS




*How can we tell if we have a good Software Requirement Specification? RUP and IEEE have listed the following qualities of an SRS.Correct Is every requirement in the SRS one that the software should meet?

Complete Does the SRS include all significant requirements, whether related to functionality, performance design constraints, attributes, or external interfaces? Have the expected ranges of input values in all possible scenarios been identified and addressed? Have responses been included to both valid and invalid input values? Do all figures, tables, and diagrams include full labels and references and definitions of all terms and units of measure? Have all TBDs (to be determined) been resolved or addressed?

Consistent Does this SRS agree with the Vision document, the use-case model and the Supplementary Specifications? Does it agree with any other higher-level specifications? Is it internally consistent, with no subset of individual requirements described which are in conflict?

Unambiguous Does each requirement have one, and only one, interpretation?

Ability to Rank Requirements Has each requirement been tagged with an identifier to indicate either the importance or stability of that particular requirement? Have other significant attributes for properly determining priority been identified?

Verifiable Is every requirement stated in the SRS verifiable? Is there some finite cost-effective process with which a person or machine can check that the software product meets the requirement?

Modifiable Are the structure and style of the SRS such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style? Has redundancy been identified, minimized, and cross-referenced?

Traceable Does each requirement have a clear identifier? Is the origin of each requirement clear? Is backward traceability maintained by explicitly referencing earlier artifacts? Is a reasonable amount of forward traceability maintained to artifacts spawned by the SRS?

Briefly review this list that is continued from the previous slide. These are the qualities that should be included in an SRS. Use the questions in the student notes to illustrate the kinds of issues that people should think about when writing good requirements specifications.These qualities of good specifications apply whether you are using a traditional approach or a use-case approach.*

See student notes.*The Design Model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The Design Model is used as essential input to activities in implementation and test. The Design Model could be included in the SRS for a very small system, but the SRS and the Design Model are usually separate documents because they have different authors and audiences.The Test Model is a collection of test cases and test procedures and their relationships. A test case can be implemented by one or more test procedures, and a test procedure may implement (the whole or parts of) one or more test cases. The Test Model and the SRS are usually separate documents because they have different authors and audiences. However, some customers, such as the U.S. Military, may require that the SRS include the Test Model.A Test Case is a set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. A Test Procedure is a set of detailed instructions for the set-up, execution, and evaluation of results for a given test case (or set of test cases).The Software Development Plan is a comprehensive, composite artifact, which gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and maintained throughout the project. Emphasize: The Design Model could be included in the SRS for a very small system, but the SRS and the Design Model are usually separate documents because they have different authors and audiences. The same is true for test documents and management documents.*

*


Most techniques discussed in this module are generally useful for eliciting information. We discuss them from the perspective of eliciting needs and features, but the same techniques can be used for all types of requirements (needs, features, software requirements), and at many levels of detail. *

























*

*



apostila sobre uml

Documents

modelagem dedadoslinguagem

the uml guia

uml prtico

projeto de software

editora campus

uml gilleanes

banco de dados

objetos guia prtico