Modelagem de Software Orientado a Objetos

Modelagem de Software Orientado a Objetos
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO CURSO DE ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE Modelagem de Software Orientado a Objetos Modelagem de Software Orientado a Objetos Parte 2- Princípios de Modelagem UML Prof. Maurício Nacib Pontuschka

Modelagem de Software Orientado a Objetos Princípios de Modelagem UML
O que é a UML? Uma linguagem para: visualização, especificação, construção e documentação de artefatos de um sistema de software

A UML é uma linguagem de visualização
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Stress how the UML is designed to promote communication using pictures rather than text. Using the UML allows the “light bulb” to go on in the minds of many people. Rather than trying to interpret a textual description of a system design, the UML offers a graphical representation of that same description. In this case, a picture is truly worth a thousand words. A UML é uma linguagem de visualização Comunicar modelos conceituais para outras pessoas tende a erros a não ser que todos falem a mesma língua. Existem coisas a respeito de sistemas de software que não podem ser entendidas sem a construção de modelos. Um modelo explícito facilita a comunicação. Typically, projects and organizations develop their own language for modeling systems, making it difficult for outsiders and new team members to understand what is going on. Communicating these conceptual models to others is prone to error unless everyone involved speaks the same language. The UML offers a set of symbols that represents well-defined semantics. One developer can write a model in the UML, and another developer can interpret that model unambiguously. There are things about a software system you can’t understand unless you build models that transcend the textual programming language. For example, the meaning of a class hierarchy can be inferred, but not directly grasped, by staring at the code for all the classes in the hierarchy. The UML is a graphical language that addresses this problem. If the developer who cut the code never wrote down the models, the information would be lost forever. At best, the information would only be partially recoverable from the implementation after the developer has moved on. Writing models in the UML addresses this issue. An explicit model facilitates communication. (The Unified Modeling Language User Guide, Booch, 1999.)

A UML é uma linguagem de especificação
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML The UML can be used to specify detailed or general models. Anyone who has worked on a project where miscommunication occurred appreciates this feature of the UML. The UML allows the modeler to specify their intentions in a clear, unmistakable manner. A UML é uma linguagem de especificação É possível, por meio da UML construir modelos de forma precisa, com um mínimo de ambigüidades. In this context, specifying means to build models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made to develop and deploy software-intensive systems. (The Unified Modeling Language User Guide, Booch, 1999.)

A UML é uma linguagem para construção
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML The UML can be used to specify detailed or general models. Anyone who has worked on a project where miscommunication occurred appreciates this feature of the UML. The UML allows the modeler to specify their intentions in a clear, unmistakable manner. A UML é uma linguagem para construção Modelos UML podem ser conectados diretamente a uma ampla variedade de linguagens de programação (Java, C++, C#, Ruby entre outras). Mapeamento para tabelas em um SGBDR ou armazenamento persistente em um SGBDOO. Permite a engenharia e engenharia reversa. In this context, specifying means to build models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made to develop and deploy software-intensive systems. (The Unified Modeling Language User Guide, Booch, 1999.)

Diagrama de Casos de Uso Diagrama de Implantação
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML UML diagrams should be treated as formal project artifacts. Each diagram created by a project team should be treated as an artifact. The UML can help alleviate some of the paper crunch that many software teams experience. A UML é uma linguagem para Documentação Documenta a arquitetura do sistema, requisitos, testes, planejamento do projeto e gestão de versionamento. Diagrama de Casos de Uso Diagrama de Classe GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) close( ) sortFileList( ) fillDocument( ) fList 1 FileList File read() fill the code.. Diagrama de Seqüência user mainWnd fileMgr : repository document : gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) Æ¯Á¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù. ÈÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù. È¸é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡ º¸¿©ÁØ´Ù. Diagrama de Implantação Window95 ¹®¼°ü¸® Å¬¶óÀÌ¾ðÆ®.EXE Windows NT ¹®¼°ü¸® ¿£Áø.EXE Windows95 Solaris ÀÀ¿ë¼¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌÅ¸º£ÀÌ½º¼¹ö ¹®¼°ü¸® ¾ÖÇÃ¸´ ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö Actor A Use Case 1 Use Case 2 Use Case 3 Actor B Project artifacts are critical in controlling, measuring, and communicating about a system during its development and after its deployment. The UML addresses the documentation of a system’s architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management. (The Unified Modeling Language User Guide, Booch, 1999.) This slide does not represent all the diagrams defined in the UML specification. For example, there is no graphic presented here for a composite structure diagram or a timing diagram. Composite structure is a more advanced modeling concept that is not covered in this course. The timing diagram is new to UML2 and will be introduced in a later module.

Experiências de parceiros
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML UML 2.0 (2004) Hístória da UML UML 1.5 (Mar, 2003) UML Experiências de parceiros UML 1.1 (Set. 1997) UML 1.0 (Jan. 1997) UML 0.9 (Jun, 1996) UML 0.91 (Out. 1996) and The UML 2.0 is defined by two complementary specifications, the Infrastructure and the Superstructure. The UML infrastructure defines foundational concepts that can be used in part or entirely by other specifications. The UML superstructure defines the complete UML. The superstructure specification is self contained and you won’t have to read the infrastructure specification unless you are concerned about configuring other specifications in parallel to UML. The UML metamodel (a description of a model) is divided into two main packages, structure and behavior with two supporting packages, auxiliary elements and profiles. • The structure package defines the static structure of the UML. The behavior package defines the dynamic structure of the UML. Each package is described by a chapter in the superstructure specification document. Feedback do público Unified Method 0.8 (OOPSLA, 1995) Booch, 1993 OMT - 2 OOSE Outros Métodos Booch 1991 OMT - 1

Contribuições para a UML
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Demonstrate that UML was developed as an industry standard with many influences. The UML is not owned and written by Rational. Do not spend a lot of time on this slide. Simply point out one or two contributors of special interest to your audience. For example, for a telephony audience, you might point out Harel and his state charts. Contribuições para a UML Rumbaugh Booch Jacobson Meyer Fusion Condições anteriores e posteriores Descrição de operações Numeração de mensagens Harel Embley UML development included incorporating ideas from numerous other methodologists. The main challenge was to construct an approach that was simple, yet allowed the modeling of a broad range of systems. The conceptual framework was established quickly, but the notational semantics took more time. Active collaboration with other industry leaders has brought unique expertise and experience into the UML effort. The UML effort was supported by a cross-section of the industry. Partners in the UML effort included HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software, Taskon, and Unisys. These partners provided contributors, reviewers, and advocates for the standardization efforts. In the end, a modeling language was created that has already withstood the test of widespread use in the industry and the scrutiny of international standardization efforts. Diagrama de estados Classes Singleton, Visão de alto nível Gamma, et.al Wirfs-Brock Frameworks, padrões, notas Responsabilidades Shlaer- Mellor Selic, Gullekson, Ward Odell Ciclo de vida de objetos ROOM (Real-Time Object-Oriented Modeling) Classificação

A linguagem não é suficiente para construir um sistema
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Emphasize here that the UML was not designed to stand alone, a process is also needed. This slide establishes the need for more than the UML. Some students may think that, if they know the UML, they’re done. They don’t need a process. Establish that the UML, while a good and necessary first step, is not enough. Just knowing the UML would be analogous to learning English by using a dictionary. Sure, all the words are there, but you still need to understand how the English language is structured before one can effectively speak. A linguagem não é suficiente para construir um sistema Desenvolvimento Baseado em Equipes The UML provides a standard for the artifacts of development (semantic models, syntactic notation, and diagrams) that must be controlled and exchanged. But the UML is not a standard for the development process. Despite all its value, you cannot achieve successful development of today’s complex systems solely by using the UML. Successful development also requires employing an equally robust development process. Linguagem de Modelagem Processo Unificado

Que tipo de processo benificia mais a UML?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML UML designers had a specific type of process in mind when the UML was first built. Que tipo de processo benificia mais a UML? A UML é independente de processo. Um processo beneficia completamente a UML quando ele é: guiado por casos de uso; centrado em arquitetura; iterativo e incremental.

Processo guiado por casos de uso
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Use cases are the cornerstone of the type of process that works best with UML. UML diagrams can be used to model a use case. Use cases are defined later in the course. Processo guiado por casos de uso Casos de uso definidos para um sistema são base para o processo de desenvolvimento inteiro. Benefícios dos casos de uso: Concisos, simples e de fácil entendimento por um grande número de stakeholders. Ajudam a sincronizar o conteúdo de diferentes modelos. Use cases are one recommended method for organizing your requirements. Instead of a bulleted list of requirements, you organize them in a way that shows how someone can use the system. By doing so, a requirement is more complete and consistent. You can also better understand the importance of a requirement from a user perspective. It’s often difficult to tell how a system does what it is supposed to do from a traditional object-oriented system model. This stems from the lack of a "thread" through the system when it performs certain tasks. Use cases are that thread because they define the behavior performed by a system. Use cases are not part of "traditional" object orientation, but their importance has become more and more apparent, further emphasized that use cases are part of the UML. Sacar dinheiro Cliente Tirar extrato

Um processo centrado na arquitetura
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Um processo centrado na arquitetura Architecture should drive the design rather than the other way around. UML diagrams allow you to reflect this. The “DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0” course explores this topic in detail. A arquitetura do sistema é usada como artefato primário na concepção, construção, gerenciamento e para envolver o sistema sob desenvolvimento.. Benefícios: Controle intelectual sobre o projeto para gerenciar a complexidade do projeto a fim de manter a integridade co sistema. Base efetiva para reúso em larga escala. Uma base para o gerenciamento do projeto. Assistência no desenvolvimento baseado em componentes. Use cases drive the process end-to-end over the entire lifecycle. The design activities are centered around architecture-centric architecture, or for software-intensive systems, software architecture. The main focus of the early iterations of a architecture-centric process is to produce and validate a software architecture, which in the initial development cycle takes the form of an executable architectural prototype that gradually evolves to become the final system in later iterations. A complex system is more than the sum of its parts, more than a succession of small independent tactical decisions. It must have some unifying, coherent structure to organize those parts systematically, and provide precise rules on how to grow the system without having its complexity “explode” beyond human understanding. Architecture provides this structure and these rules. By clearly articulating the major components and the critical interfaces among them, architecture lets you reason about reuse, both internal reuse (the identification of common parts), and external reuse (the incorporation of ready-made, off-the-shelf components). Architecture can also help reuse on a larger scale. That is, the reuse of the architecture itself in the context of a product line that addresses different functionality in a common domain.

Um processo iterativo e incremental
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Design the system in small digestible pieces. UML diagrams can enable one to design in an iterative fashion. Developing iteratively means developing in small pieces that we call use-case realizations. Um processo iterativo e incremental Riscos críticos são resolvidos antes de realizar grandes investimentos. Iterações iniciais habilitam um feedback de usuário antecipado. Testes e integração são contínuos. Foco em etapas objetivas a curto prazo. O progresso é mensurado através do fornecimento de implementações. Implementações parciais podem ser disponibilizadas. An iterative approach allows users to be involved in a meaningful way throughout the project life cycle. Since each iteration produces an executable release, users can observe the partially executing system and provide meaningful feedback to their level of satisfaction. This ensures that the final system delivered to users is acceptable. Continuous testing and integration ensures that, at every iteration, the pieces all fit together and that the system-level requirements (for example, performance and capacity) are being met. The short-term focus of an iteration is an objective measure of “doneness.” Either a class is included in the build or it’s not. It can’t be 90 percent done. Either a test is executed successfully or it’s not. There is very little room for subjective estimates. In spite of the best efforts of the development team, not all system features may be complete on the original delivery date. With a waterfall approach, this would usually mean that nothing was ready to be delivered (everything is 90 percent done). With an iterative approach, most of the system is already fully tested and operational. In many cases, there is value in delivering the partial system on the promised date with the remaining features incorporated at a later time. This can be important when a user has a critical need for some of the new functionality provided by the system or it may help the training and installation process to proceed on schedule. An iterative approach can avoid inconvenient re-planning and re-assignment of resources.

Desenvolvimento Iterativo
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Define iterative development for the students. It is not necessary to go into great detail at this time. The Mastering Object-Oriented Analysis and Design with UML class discusses this topic. In the iterative approach, the waterfall is applied to a single increment of the system at a time. Each iteration produces an executable. Verify that the waterfall concept is understood by the students. Desenvolvimento Iterativo T E M P O Iteração 1 Iteração 2 Iteração 3 I C D R T In the diagram above, the following abbreviations are used. R Requirements analysis D Design C Coding, unit testing I Implementation T Subsystem and system test Iterative processes were developed in response to these waterfall characteristics. With an iterative process, apply the waterfall steps iteratively. Instead of developing the whole system at once, select and develop an increment (a subset of system functionality), then another increment, and so on. Develop the first increment based on risk, with the highest priority risks to be developed first. To address the selected risk(s), choose a subset of use cases. Develop the smallest number of use cases that allow objective verification (like a set of executable tests) of the risks that you’ve chosen. Select the next increment to address the next highest risk, and so on. Thus, you apply the waterfall within each iteration and the system evolves incrementally. Iterações mais recentes endereçam os maiores riscos. Cada iteração produz uma versão executável, um incremento adicional do sistema. Cada iteração inclui integração e teste.

O que é a UML? Descreva cada um de seus benefícios.
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Check to see if the students comprehended the material. A. A model is a simplification of reality. B. The three viewpoints of MDA are: (1) CIM – focus is on environment and requirements; (2) PIM – focus is on system operation, independent of the platform; (3) PSM – focus is on detailed usage on specific platform. C. The four principles of modeling are: (1) The models you create profoundly influence how a problem is attacked and how a solution is shaped; (2) Every model may be expressed at different levels of precision; (3) The best models are connected to reality; (4) No single model is sufficient. D. The UML is a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. E. The UML is largely process independent but consider a process that is: use-case driven, architecture-centric, and iterative and incremental. F. An iteration encompasses the development activities that lead to a product release - a stable, executable versions of product, together with any other peripheral elements necessary to use this release. Revisão O que é a UML? Descreva cada um de seus benefícios. Quais características de processo melhor se adapta à UML? Descreva cada característica. O que é uma iteração?

Dúvidas?

Modelagem de Software Orientado a Objetos
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO CURSO DE ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE Modelagem de Software Orientado a Objetos Modelagem de Software Orientado a Objetos Parte 2- Princípios de Modelagem UML Modelagem por Casos de Uso Prof. Maurício Nacib Pontuschka

Demostrar como ler e interpretar:
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Introduce the objectives for the module. Objetivos Descrever o comportamento de um sistema e mostrar como capturá-lo em um modelo. Demostrar como ler e interpretar: um diagrama de casos de uso; um diagrama de atividades.

Conceitos na modelagem de casos de uso Diagramas de caso de uso
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Onde estamos? Conceitos na modelagem de casos de uso Diagramas de caso de uso Diagramas de atividade

O que comportamento do sistema?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Explain what is meant by “system behavior.” How do you capture system behavior? O que comportamento do sistema? Comportamento do sistema é como o sistema age e reage. É representado pelas ações e atividades de um sistema. O comportamento do sistema é capturado em casos de uso. Casos de uso descrevem as interações entre sistema e (partes do) ambiente. No system exists in isolation. Every system interacts with people or automated systems for some purpose. These interactions result in some sort of predictable result. This predictable result is system behavior. Use cases are the mechanism for capturing the desired behavior for the system that is under development, but do not specify how the behavior is to be implemented. The UML specifies a model for communicating system behavior, the use-case model.

O que é um modelo de casos de uso?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Introduce the students to use-case models. Remember, this is probably the first time that they have seen a use-case model. Actors and use cases are discussed on the next several slides. Use this slide to set the context for that discussion. You might describe a use-case model as a menu. People can place themselves in a role (actor) and see the options available to them on this system. A use-case model does NOT imply the order that use cases execute. O que é um modelo de casos de uso? Um modelo descreve um requisito funcional do sistema em termos de casos de uso. Um modelo das necessidades pretendidas do sistema (casos de uso) e seu ambiente (atores). Ver boletim de notas Estudante Matricular em cursos Requerer certificado A use-case model describes a system’s functional requirements in terms of use cases. The use-case model is a model of the system's intended functions and its environment and serves as a contract between the customer and the developers. Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle. The customer approves the use-case model. When you have that approval, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development. Participants use it to better understand the system. Designers use it as a basis for their work and to get a system overview. Testers use it to plan testing activities (use case and integration testing) as early as possible. Those developing the next version of the system use it to understand how the existing version works. Documentation writers review the use cases as a basis for writing the system's user guides. The architect checks the use-case model to identify architecturally significant functionality. The manager uses it to plan and follow up on the use-case modeling and also the subsequent design.

Quais são os benefícios de um modelo de casos de uso?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Yes, you are selling the concept of a use-case model here. Many of your students may not immediately recognize the need for the use-case model because it is so simple. This slide is intended to bring out some of the problems that this model resolves. Feel free to add your own experiences here. Talking about this slide, mention: Communication with the end users and domain experts Provides buy-in at an early stage of system development Insures a mutual understanding of the requirements Identification of system users and what the system should do Considers the requirements for the system interfaces Verification that all requirements have been captured The development team understands the requirements Quais são os benefícios de um modelo de casos de uso? Comunicação Identificação Verificação Caso de Uso Comunicação Verificação Identificação There are many ways to model a system, each of which may serve a different purpose. However, the most important role of a use-case model is to communicate the system's behavior to the customer or end user. Consequently, the model must be easy to understand. Communication with the end users and domain experts Provide buy-in at an early stage of system development Insure a mutual understanding of the requirements Identification of system users and what the system should do The requirements for the system interfaces Verification that all requirements have been captured The development team understands the requirements Actors are the users and any other system that may interact with the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actor’s needs, ensuring that the system turns out to be what the users expected. Usuário final Especialista no domínio Usuários

Conceitos principais na modelagem de casos de uso
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Introduce the two major concepts in use-case modeling. Do not go into great detail explaining what an actor and use case are in this slide. Detailed actor and use-case slides are coming up soon. Conceitos principais na modelagem de casos de uso Um ator representa qualquer coisa que interage com o sistema. Um caso de uso descreve uma seqüência de eventos, realizados pelo sistema, que produzam resultados de valor observáveis a um ator em particular. Ator An actor represents a coherent set of roles that one plays when interacting with these use cases. Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. A use case describes what a system does, but it does not specify how it does it. Caso de Uso

Explain the concept of actors to the students. Remember, this is new to them. Be sure that the class understands that an actor is NOT JUST A PERSON. An actor is anything that interacts with the system and is external to the system. Illustrate this concept by using the example of an ATM machine. Ask the class to identify some potential actors. Answers may include: bank customer, maintenance worker, bank teller, bank system, credit card system, and so on. If you aren’t allowed to change it then it is an actor. O que é um ator? Atores representam papéis que os usuários do sistema podem assumir. Podem representar uma pessoa, uma máquina ou outros sistemas. Podem trocar informações com o sistema ativamente. Podem ser fornecedores de informação. Podem ser receptores passivos de informação. Atores não fazem parte do sistema Atores são EXTERNOS. Ator An Actor can be defined as: Anything that exchanges data with the system and is external to the system. To fully understand the system's purpose you must know who the system is for. Different user types are represented as actors. An actor can be a user, external hardware, or another system. An actor may actively interchange information with the system, be a passive recipient of information, or can represent a human, a machine or another system. The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, which means they can be one and the same actor. In which case, each user constitutes an instance of the actor. In some situations, only one person plays the role modeled by an actor. For example, there may be only one individual playing the role of system administrator for a rather small system. The same user can also act as several actors. That is, the same person can take on different roles.

Explain the concept of a use case to the students. This material is also new to them. Use cases focus on WHAT the system does, not HOW it does it. A use case has a set of properties that includes a brief description, flow of events, special requirements, activity diagrams, and so on. These are discussed in more detail later in this module. Use cases are enclosed in the use-case model artifact. That is, use cases are properties of the use-case model. O que é um caso de uso? Define um conjunto de instâncias de casos de uso onde cada instância é uma seqüência de ações que o sistema executa e que produz resultados de valor a um ator em particular. Um caso de uso modela um dialogo entre um ou mais atores com o sistema. Um caso de uso descreve as ações que o sistema realiza para produzir algo de valor ao ator. A Use-Case can be defined as: A sequence of actions a system performs that yields an observable result of value to a particular actor. Actions - An action is a computational or algorithmic procedure. It is invoked either when the actor provides a signal to the system or when the system receives a time event. An action may imply signal transmissions to either the invoking actor or other actors. An action is atomic. That is, it is performed either entirely or not at all. System performs - The system provides the use case. An actor communicates with a use-case instance of the system. An observable result of value - You can put a value on a successfully performed use case. A use case should ensure that an actor can perform a task that has an identifiable value. This is important to determine the correct level or granularity for a use case. Correct level refers to achieving use cases that are not too small. In certain circumstances, you can use a use case as a planning unit that includes individuals playing the role of an actor to the system. A particular actor - The actor is key to finding the correct use case because the actor helps to avoid use cases that are too large. As an example, consider a visual modeling tool. There are two actors to this application: a developer, someone who develops systems using the tool as support and a system administrator, someone who manages the tool. Each of these actors has its own demands on the system and requires its own set of use cases. Caso de Uso

Um caso de uso modela um diálogo entre atores e o sistema.
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Casos de Uso e Atores Show the relationship between use cases and actors. A use case can initiate communication with an actor. Usually, this occurs with a non-human actor. The <<communicate>> association stereotype was valid for the UML1 example profiles UML Profile for Software Development Process, which is based on the Unified Process for software engineering, and the UML Profile for Business Modeling. Since an association is the only valid relationship that can exist between actors and use cases, UML 2 has dropped the stereotype. Um caso de uso modela um diálogo entre atores e o sistema. Um caso de uso é iniciado por um ator para invocar uma determinada funcionalidade no sistema. It is important to show how actors relate to the use case. Therefore, on finding a use case, establish the actors that interact with it. To do this, you must define an association that helps to clarify the communication between the actor and use case. Actors may be connected to use cases only by an association. An association between an actor and a use case indicates that the actor and the use case instance of the system communicate with one another, each one able to send and receive messages. The arrow head is optional but it’s commonly used to denote the initiator. Ator Associação Caso de Uso

Como você lê este diagrama?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML In this slide, give students a chance to read a use-case diagram. Answers to student notes: 1. Student can perform: View Report Card, Register For Courses, and Login. A Professor can: Login, Select Courses to Teach, and Submit Grades. The Course Catalog is involved in: Register for Courses and Select Courses to Teach. Disclaimer: Login is a controversial use case. The goal of this course is not to determine when/how/why one should use the Login use case, it is part of the Mastering Object Oriented Analysis and Design with UML curriculum so that instructors can have a short use case to demonstrate exercises. It is only here for instructional purposes. 2. Charlie can: View Report Card, Register for Courses, Login, Select Courses to Teach, and Submit Grades. 3. This is a Course Registration System. 4.The Professor initiates the Select Courses to Teach and the Course Catalog is a participant; the Registrar initiates the Close Registration and the Billing System is a participant. 5. Of course, this is a trick question. You can’t make that assumption from looking at this model. It isn’t intended to show order. Como você lê este diagrama? Consulta Boletim Estudante Matricula-se em cursos Seleciona cursos para ministrar Publica notas Professor Funcionário Sistema de Cobrança Mantém cadastro de professor Mantém informações do estudante Fecha matrícula Catálogo de cursos Answer the following questions: Which use cases can a student perform? A professor? The Course Catalog? If Charlie is a student and professor, which use cases can he execute? Describe the functionality of this system. Describe the actor relationships for the Close Registration and Select Courses To Teach use cases. Which use case needs to run first, Register for Courses or View Report Card?

O que é um diagrama de atividades?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML The goal of this section is to introduce the students to the concept of an activity diagram. You are not expected to teach them everything about this diagram at this time. Activity diagrams can also be used to model the workings of an operation, an object, business modeling, or anything that involves modeling the sequential steps in a computational process. This course focuses on using activity diagrams to model the flow of events in a use case. O que é um diagrama de atividades? Um diagrama de atividades em um modelo de casos de uso podem ser usados para capturar as atividades e ações executadas em um caso de uso. É em sua essência um diagrama de fluxo evidenciando o controle do fluxo entre as atividades. Fluxo de Eventos Este caso de uso inicia quando o Funcionário requisitar que o sistema feche a matrícula. 1. O sistema verifica se existe uma matrícula em andamento. Se estiver, uma mensagem é exibida ao Funcionário e o caso de uso termina. O fechamento do processo de matrícula não pode ser fechado se houve matrícula em andamento. 2. Para cada oferta de curso o sistema verifica se um professor está designado a ministrar o curso oferecido e pelo menos três estudantes tenham sido matriculados. No caso positivo, o sistema realiza a oferta de curso para cada horário dos cursos. The workflow of a use case describes that which needs to be done by the system to provide the value the served actor is looking for. It consists of a sequence of activities and actions that together produce something for the actor. The workflow often consists of a basic flow and one or several alternative flows. The structure of the workflow can be described graphically with the help of an activity diagram. Atividade 1 Atividade 3 Atividade 2

If a high-level activity is viewed as a tree of nested activities, the leaves of the tree are actions. Actions include arithmetic and string functions, manipulations of objects and their values, communications among objects, and similar things. Kinds of actions include: Accept call Accept event Apply function Broadcast event Call Create Destroy Raise exception Read Reply Return Send Time Write O que é uma atividade? Uma especificação do comportamento expresso como um fluxo de execução através de uma seqüência de unidades subordinadas. Unidades subordinadas incluem atividades internas e resultantes de ações individuais. Pode conter expressões booleanas quando a atividade é iniciada ou finalizada. <<Pré-condição>> Boolean restrição Atividade 5 <<Pós-condição>> Boolean restriçãot Atividade 4 Atividade 2 An activity is notated as an activity diagram. An activity definition is shown as a large rounded border containing a graph of node symbols and flow arrows representing the decomposition of the activity into its constituents. Activity preconditions and postconditions use the note notation with the keywords <<Precondition>> and <<Postcondition>> respectively. An action is a primitive activity which is the smallest computation that can be expressed. An action is an activity that does something to the state of the system or extracts information from it. An action is drawn as a rectangle with rounded corners. Action preconditions and postconditions use the note notation with the keywords <<localPrecondition>> and <<localPostcondition>> respectively.

Exemplo: Diagrama de Atividades
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML Walk the students through the activity diagram and explain each component (decision, fork, join, and so on). Exemplo: Diagrama de Atividades Decisão Atividade/Ação Seleciona Curso Threads Paralelos [ apaga curso ] Apaga curso [ adiciona curso ] Synchronization Bar (Fork) Condição de fluxo Verifica Calendário Verifica Pré-requisitos An activity diagram may include the following elements: Activity/Action represents the performance of a step within the workflow. Transitions show the activity/action that follows. Decisions evaluate conditions defined by guard conditions. These guard conditions determine which of the alternative transitions will be made and, thus, which activities are performed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a use case. Synchronization bars show parallel sub-flows. They allow you to show concurrent threads in the workflow of a use case. Barra de sincronização (Join) [ verificação ok ] [verificação falha] Matricular no curso Resolver Conflitos Transição Atualizar Calendário

Descrição textual de casos de uso
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML A. System behavior is how a system acts and reacts. It is an outwardly visible and testable activity of a system. B. A use-case model describes a system’s functional requirements in terms of use cases. It is used to communicate with the end users and the domain experts. A benefit includes buy-in at an early stage of system development. C. An actor is anything that exchanges data with the system and is external to the system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. D. An activity diagram in the use-case model can be used to capture the activities in a use case. It is essentially a flow chart, showing flow of control from activity to activity. Descrição textual de casos de uso É possível também descrever um caso de uso utilizando outros recursos que não diagramas de atividades como por exemplo, por meio de textos ao invés de diagramas. O texto a seguir descreve um caso de uso sem a utilização de diagramas.

A. System behavior is how a system acts and reacts. It is an outwardly visible and testable activity of a system. B. A use-case model describes a system’s functional requirements in terms of use cases. It is used to communicate with the end users and the domain experts. A benefit includes buy-in at an early stage of system development. C. An actor is anything that exchanges data with the system and is external to the system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. D. An activity diagram in the use-case model can be used to capture the activities in a use case. It is essentially a flow chart, showing flow of control from activity to activity. MN# 01 – Publicar Notas Ator Principal: Professor Pré-Condições: O Professor deve estar alocado em algum curso em andamento. Pós-Condições: As notas de uma determinada turma do professor estará com as notas de seus alunos lançadas. FLUXO PRINCIPAL ATOR SISTEMA 1. Acessa a opção de publicar notas. 2. Solicita a turma. 3. Informa a turma. 4. Mostra tela com os nomes dos alunos com os respectivos campos para digitação das notas. 5. Digita as notas dos alunos. 6. Registra e disponibiliza as notas dos alunos.

A. System behavior is how a system acts and reacts. It is an outwardly visible and testable activity of a system. B. A use-case model describes a system’s functional requirements in terms of use cases. It is used to communicate with the end users and the domain experts. A benefit includes buy-in at an early stage of system development. C. An actor is anything that exchanges data with the system and is external to the system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. D. An activity diagram in the use-case model can be used to capture the activities in a use case. It is essentially a flow chart, showing flow of control from activity to activity. FLUXO ALTERNATIVO FLUXO DE ORIGEM: FP FLUXO DE RETORNO: FP ATOR SISTEMA 4. Informa que a turma não existe 5. Solicita abertura de nova turma. 6. Solicita o nome da nova turma 7. Informa o nome. 8. Registra o nome da turma e continua no passo 4 do Fluxo Principal. FA1

A. System behavior is how a system acts and reacts. It is an outwardly visible and testable activity of a system. B. A use-case model describes a system’s functional requirements in terms of use cases. It is used to communicate with the end users and the domain experts. A benefit includes buy-in at an early stage of system development. C. An actor is anything that exchanges data with the system and is external to the system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. D. An activity diagram in the use-case model can be used to capture the activities in a use case. It is essentially a flow chart, showing flow of control from activity to activity. FE1 FLUXO EXCEPCIONAL FLUXO DE ORIGEM: FP FLUXO DE RETORNO: - ATOR SISTEMA 4. Informa que a turma não existe 5. Cancela a operação. OBSERVAÇÃO Embora nestes slides os fluxos tenham sido colocados de forma separada para uma melhor visualização no formato de apresentação, estes podem ser contínuos em uma mesma tabela.

O que é comportamento do sistema?
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML A. System behavior is how a system acts and reacts. It is an outwardly visible and testable activity of a system. B. A use-case model describes a system’s functional requirements in terms of use cases. It is used to communicate with the end users and the domain experts. A benefit includes buy-in at an early stage of system development. C. An actor is anything that exchanges data with the system and is external to the system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. D. An activity diagram in the use-case model can be used to capture the activities in a use case. It is essentially a flow chart, showing flow of control from activity to activity. Revisão O que é comportamento do sistema? O que é modelo de casos de uso? Quais são os seus benefícios? O que é um ator? E um caso de uso? O que é um diagrama de atividades?

Dados: Desenhe: Exercício Casos de uso, atores e associações
Modelagem de Software Orientado a Objetos Princípios de Modelagem UML The goal of the exercise is to have the students draw a UML diagram. Remember, all of this is new to them and they may struggle with drawing the diagrams the right way. The “givens” are provided in the student notes for this slide. The students are provided with a textual description of a use case and must then build a diagram that accurately reflects the textual description. Exercício Dados: Casos de uso, atores e associações Desenhe: Um diagrama de casos de uso Ações, estados e atividades Um diagrama de atividades 1. Draw a use-case diagram using the following elements: There are four actors on the diagram: Prospective Buyer, System, Loan System, and Credit Reporting System. There are four use cases on the diagram: Find Realtor, Maintain Personal Planner, Search for a Home, and Apply for a Loan. Document the following association; Prospective Buyer to Find Realtor Prospective Buyer to Maintain Personal Planner Prospective Buyer to Search For A Home Prospective Buyer to Apply For A Loan Maintain Personal Planner to System Search for a Home to System Apply for a Loan to Loan System Apply for a Loan to Credit Reporting System Study the diagram that you have drawn. What does it say? What doesn’t it say? Describe the functionality that a Prospective Buyer expects from the system? 2. Draw an activity diagram that reflects the following four action states: Choose Profile, Find Buyer Profile, Log on, and Create New Profile. Starting with Choose Profile, go to Find Buyer Profile; then go from the Find Buyer Profile to Create New Profile, providing a profile does NOT exist. If a profile does exist, you can go to Log on.

Fábio é um construtor de casas para condomínios de alto padrão em uma cidade do interior de São Paulo. Em suas atividades profissionais ele necessita realizar alguns controles de forma a garantir que seus projetos sejam executados com qualidade. Uma das principais necessidades de Fábio é a de controlar a compra, utilização e estoque de materiais de construção. Muitas vezes materiais acabam sendo comprados em duplicidade, uma vez que o chefe de obras possui uma pequena verba para compras de materiais em situações de emergência. Outro controle que representa um fator crítico em suas atividades é controle de mão de obra. Os operários devem ser cadastrados e acompanhados em termos de horas trabalhadas a fim de realizar os pagamentos no final da semana. Fábio gostaria de criar um mapa de atividades das obras e de vincular os operários a cada uma das atividades a fim de permitir otimizações no processo.

Dúvidas?

Modelagem de Software Orientado a Objetos

Apresentações semelhantes

Apresentação em tema: "Modelagem de Software Orientado a Objetos"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Modelagem de Software Orientado a Objetos

Apresentações semelhantes

Apresentação em tema: "Modelagem de Software Orientado a Objetos"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback