DOCSLIB.ORG

Interaction Overview Diagram: an Overview in Which Nodes Represent Communication Diagrams

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Interaction Overview Diagram: an Overview in Which Nodes Represent Communication Diagrams Avancier Avancier Methods UML distilled Including some Figures from the UML 2.4.1 standard (Know that UML is enormous It would take a week to learn all of it) Copyright Avancier Limited 2012 Unified Modeling Language Avancier ► “A standard language for writing software blueprints” ► “to visualise, specify, construct and document ► the artefacts of a software-intensive system” ► A specification language ► Grew out of need to specify an OO program ► Not originally designed for architects, business analysis or database design, but since extended to cover them. ► Bear in mind that a notation is not a panacea Copyright Avancier Limited 2012 UML is for OO system design Avancier All system design is about: ■ Defining the requirements for the system ■ Dividing the system into modules ■ Defining how those modules are related to each other. In OO system design ■ The requirements are defined as use cases ■ The modules are called classes ■ The two principal kinds of relationship are association and generalisation. Copyright Avancier Limited 2012 UML applies to object-oriented problem solving. Avancier ► UML embodies the tenets of object-oriented problem solving ► The domain is that part of the world that a system monitors or directs, containing entities and processes to be remembered or directed ► The run-time software system represents each entity and process as an object which has: ■ a structure or state - attribute values ■ behaviours – activities it can perform - operations ► Objects interact by sending each other messages. ► Each object is regarded as an instance of a class ► The model describes both domain and run-time software in terms of classes. A class is a template for a set of objects that defines ■ Structure – attribute types (data types) ■ Behaviour - operations (methods or functions) Copyright Avancier Limited 2012 But at a first-level of understanding, Avancier ► You can learn and use a lot of UML without knowledge of object-oriented software design ► UML is a set of diagram types. ► Each diagram is composed of ■ Boxes – nodes - things ■ Lines – arcs – relationships between things Copyright Avancier Limited 2012 14 UML diagram types Avancier ► Notice the division between structure and behaviour diagrams What a systems What a system is made of does/offers Copyright Avancier Limited 2012 Most popular diagram types Avancier Most popular Next most popular Copyright Avancier Limited 2012 A vastly simplified meta model of UML entities Avancier Structure ► Key entities in UML diagrams Class Behaviour Feature Relationship Process Behavioural Structural Feature Feature State machine Event State Operation Attribute Association Generalisation Action Transition Sequence Collaboration Guard Class Association Condition Action Role Role Message Copyright Avancier Limited 2012 Structure diagrams Avancier ► Class diagram: a system's classes, with their attributes and interrelationships ► Deployment diagram: execution environments and artefacts deployed onto hardware. ► Component diagram: components and the dependencies among these components. ► Package diagram: logical groupings in a system and dependencies among groupings. ► Composite structure diagram: the internal structure and possible collaborations of a class ► Object diagram: the structure of instances in a system at a specific time. ► Profile diagram: show stereotypes as classes at the metamodel level Copyright Avancier Limited 2012 Class diagram Avancier ► What are the basic components of a software system? ► How are they related? ► Software architects decompose applications into classes (not only data-entity-centric classes like the ones shown here). Copyright Avancier Limited Deployment diagram: Avancier ► execution environments and artefacts deployed onto hardware. Copyright Avancier Limited 2012 Component diagram: Avancier ► components and the dependencies among these components. ■ Components shown as boxes. ■ Interfaces shown as lollipops. ■ Dependencies shown in two ways. UML 1 Dependency arrow Component Component UML 2 Lollipop grabber Component Component Copyright Avancier Limited 2012 Package diagram: Avancier ► logical groupings in a system and dependencies among groupings. dependency Package Name Package Name Package Name Class 1 Class 2 Class 3 Copyright Avancier Limited 2012 Not illustrated here Avancier ► Composite structure diagram: the internal structure and possible collaborations of a class ► Object diagram: the structure of instances in a system at a specific time. ► Profile diagram: show stereotypes as classes at the metamodel level Copyright Avancier Limited 2012 Behaviour diagrams Avancier ► Use case diagram: processes that actors of a system are involved in, and dependencies between use cases. ► Activity diagram: step-by-step flow of work - shows the overall flow of control. ► State machine diagram the states and state transitions of a process. ► Interaction diagram ■ Sequence diagram: a sequence of message-based interactions between objects or components ■ Communication diagram: a sequence of message-based interactions between objects or components ■ Interaction overview diagram: an overview in which nodes represent communication diagrams. ■ Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints. Copyright Avancier Limited 2012 Use case diagram: Avancier ► processes that actors of a system are involved in… Copyright Avancier Limited 2012 Activity diagram: Avancier ► step-by-step flow of work ► shows the overall flow of control. Copyright Avancier Limited 2012 State machine diagram Avancier ► the states and state transitions of a process. Copyright Avancier Limited 2012 State machine diagram Avancier Similar to activity diagrams Nodes: states rather than steps Lines: transitions "decorated” to indicate the triggering method call or condition Birth Born Change P’word 18th Birthday Logged On Id match Log Off Voter Waiting Vote Disconnection Authentication Death Enter Id Dead Logged Off Id mismatch Copyright Avancier Limited 2012 Interaction diagram Communication diagram: Avancier ► a sequence of message-based interactions between objects or components Copyright Avancier Limited 2012 Not illustrated here Avancier ► Interaction overview diagram: an overview in which nodes represent communication diagrams. ► Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints. Copyright Avancier Limited 2012 UML diagram usage Avancier ► From “Empirical Assessment of MDE in Industry” ► Most of the diagram types appear in our training Copyright Avancier Limited 2012 Avancier training focuses on the more popular diagrams Avancier Structure diagrams ► Class diagram: a system's classes, with their attributes and interrelationships ► Deployment diagram: execution environments and artefacts deployed onto hardware. ► Component diagram: components and the dependencies among these components. ► Composite structure diagram: the internal structure and possible collaborations of a class ► Object diagram: the structure of instances in a system at a specific time. ► Package diagram: logical groupings in a system and dependencies among groupings. ► Profile diagram: show stereotypes as classes at the metamodel level Behaviour diagrams ► Activity diagram: step-by-step flow of work - shows the overall flow of control. ► State machine diagram the states and state transitions of a process. ► Use case diagram: processes that actors of a system are involved in, and dependencies between use cases. ► Interaction diagram ■ Sequence diagram: a sequence of message-based interactions between objects or components ■ Communication diagram: a sequence of message-based interactions between objects or components ■ Interaction overview diagram: an overview in which nodes represent communication diagrams. ■ Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints. Copyright Avancier Limited 2012 Useful references Avancier For more on diagrams and notations http://avancier.website UML reference card http://www.holub.com/goodies/uml/ UML tutorial http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm UML1.1 http://umlcenter.visual-paradigm.com/umlresources/nota_11.pdf Copyright Avancier Limited 2012 .
Load more

Recommended publications
  • Model Based Systems Engineering Approach to Autonomous Driving
    DEGREE PROJECT IN ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018 Model Based Systems Engineering Approach to Autonomous Driving Application of SysML for trajectory planning of autonomous vehicle SARANGI VEERMANI LEKAMANI KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Author Sarangi Veeramani Lekamani [email protected] School of Electrical Engineering and Computer Science KTH Royal Institute of Technology Place for Project Sodertalje, Sweden AVL MTC AB Examiner Ingo Sander School of Electrical Engineering and Computer Science KTH Royal Institute of Technology Supervisor George Ungureanu School of Electrical Engineering and Computer Science KTH Royal Institute of Technology Industrial Supervisor Hakan Sahin AVL MTC AB Abstract Model Based Systems Engineering (MBSE) approach aims at implementing various processes of Systems Engineering (SE) through diagrams that provide different perspectives of the same underlying system. This approach provides a basis that helps develop a complex system in a systematic manner. Thus, this thesis aims at deriving a system model through this approach for the purpose of autonomous driving, specifically focusing on developing the subsystem responsible for generating a feasible trajectory for a miniature vehicle, called AutoCar, to enable it to move towards a goal. The report provides a background on MBSE and System Modeling Language (SysML) which is used for modelling the system. With this background, an MBSE framework for AutoCar is derived and the overall system design is explained. This report further explains the concepts involved in autonomous trajectory planning followed by an introduction to Robot Operating System (ROS) and its application for trajectory planning of the system. The report concludes with a detailed analysis on the benefits of using this approach for developing a system.
    [Show full text]
  • Information Technology and Software Development
    Course Title: Information Technology and Software Development NATIONAL OPEN UNIVERSITY OF NIGERIA SCHOOL OF SCIENCE AND TECHNOLOGY COURSE CODE: CIT 703 COURSE TITLE: Information Technology and Software Development National Open University of Nigeria, Victoria Island, Lagos Page 1 Course Title: Information Technology and Software Development Course Code Course Title Information Technology and Software Development Course Developer/Writer Eze, Festus Chux Department of Computer Science Ebonyi State University Abakaliki Course Editor Programme Leader Course Coordinator National Open University of Nigeria, Victoria Island, Lagos Page 2 Course Title: Information Technology and Software Development Introduction Information Technology and Software Development is a three credit load course for all the students offering Post Graduate Diploma (PGD) in Computer Science, Information Technology and other allied courses. Software Development is a major branch in computing and information Technology. A software development professional oversees the processes of software development, the management of software development project, the maintenance of the installed software in an organisation. For sometime the field has been dominated with what is the definitive process of software development. Furthermore there has been the running battle between professionals and managers on who should control a software development project. There is an attempt to classify it as any other project that an organisation handles hence anybody could manage it. Whereas others see it as a highly professional issue that requires high precision in design, management and implementation. However, software development is all involving. It involves the user (client) whose interest is paramount. The developing organisation and her professionals ( team)are of great importance. Therefore a successful exercise can only take place when all these variegated interests are harmonised.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis
    APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Sandeep K. Shukla, Chair Lamine Mili Alireza Haghighat Chao Wang Yi Deng April 3, 2015 Blacksburg, Virginia Keywords: AADL, CPS, Model-based code synthesis, correct-by-construction code synthesis, Polychrony, code generators, OSATE, Ocarina Copyright 2015, Matthew E. Anderson APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson (ABSTRACT) The development of high integrity embedded systems remains an arduous and error-prone task, despite the efforts by researchers in inventing tools and techniques for design automa- tion. Much of the problem arises from the fact that the semantics of the modeling languages for the various tools, are often distinct, and the semantics gaps are often filled manually through the engineer's understanding of one model or an abstraction. This provides an op- portunity for bugs to creep in, other than standardising software engineering errors germane to such complex system engineering. Since embedded systems applications such as avionics, automotive, or industrial automation are safety critical, it is very important to invent tools, and methodologies for safe and reliable system design. Much of the tools, and techniques deal with either the design of embedded platforms (hardware, networking, firmware etc), and software stack separately. The problem of the semantic gap between these two, as well as between models of computation used to capture semantics must be solved in order to design safer embedded systems.
    [Show full text]
  • Systems Engineering with Sysml/UML Morgan Kaufmann OMG Press
    Systems Engineering with SysML/UML Morgan Kaufmann OMG Press Morgan Kaufmann Publishers and the Object Management Group™ (OMG) have joined forces to publish a line of books addressing business and technical topics related to OMG’s large suite of software standards. OMG is an international, open membership, not-for-profi t computer industry consortium that was founded in 1989. The OMG creates standards for software used in government and corporate environments to enable interoperability and to forge common development environments that encourage the adoption and evolution of new technology. OMG members and its board of directors consist of representatives from a majority of the organizations that shape enterprise and Internet computing today. OMG’s modeling standards, including the Unifi ed Modeling Language™ (UML®) and Model Driven Architecture® (MDA), enable powerful visual design, execution and maintenance of software, and other processes—for example, IT Systems Modeling and Business Process Management. The middleware standards and profi les of the Object Management Group are based on the Common Object Request Broker Architecture® (CORBA) and support a wide variety of industries. More information about OMG can be found at http://www.omg.org/. Related Morgan Kaufmann OMG Press Titles UML 2 Certifi cation Guide: Fundamental and Intermediate Exams Tim Weilkiens and Bernd Oestereich Real-Life MDA: Solving Business Problems with Model Driven Architecture Michael Guttman and John Parodi Architecture Driven Modernization: A Series of Industry Case Studies Bill Ulrich Systems Engineering with SysML/UML Modeling, Analysis, Design Tim Weilkiens Acquisitions Editor: Tiffany Gasbarrini Publisher: Denise E. M. Penrose Publishing Services Manager: George Morrison Project Manager: Mónica González de Mendoza Assistant Editor: Matt Cater Production Assistant: Lianne Hong Cover Design: Dennis Schaefer Cover Image: © Masterfile (Royalty-Free Division) Morgan Kaufmann Publishers is an imprint of Eslsevier.
    [Show full text]
  • Examples of UML Diagrams
    UML Diagrams Examples Examples by Technology or Application Domain Online shopping UML diagrams Ticket vending machine UML diagrams Bank ATM UML diagrams Hospital management UML diagrams Digital imaging and communications in medicine (DICOM) UML diagrams Java technology UML diagrams Application development for Android UML diagrams Software licensing and protection using SafeNet Sentinel HASP security solution Examples by Types of Diagrams Activity diagram examples Class diagram examples Communication diagram examples Component diagram examples Composite structure diagram examples Deployment diagram examples Information flow diagram example Interaction overview diagram examples Object diagram example Package diagram examples Profile diagram examples http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 1 of 33 Sequence diagram examples State machine diagram examples Timing diagram examples Use case diagram examples Use Case Diagrams Business Use Case Diagrams Airport check-in and security screening business model Restaurant business model System Use Case Diagrams Ticket vending machine http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 2 of 33 Bank ATM UML use case diagrams examples Point of Sales (POS) terminal e-Library online public access catalog (OPAC) http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 3 of 33 Online shopping use case diagrams Credit card processing system Website administration http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 4 of 33 Hospital
    [Show full text]
  • UML Why Develop a UML Model?
    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes
    [Show full text]
  • UML Class Diagrams UML Is a Graphical Language for Recording Aspects of the Requirements and Design of Software Systems
    The Unified Modeling Language UML class diagrams UML is a graphical language for recording aspects of the requirements and design of software systems. Nigel Goddard It provides many diagram types; all the diagrams of a system together form a UML model. Three important types of diagram: School of Informatics 1. Use-case diagram. Already seen in requirements lecture. University of Edinburgh 2. Class diagram. Today. 3. Interaction diagram. In the future. Reminder: a simple use case diagram A class Reserve book Browse Browser BookBorrower Book Borrow copy of book A class as design entity is an example of a model element: the Return copy of book rectangle and text form an example of a corresponding presentation element. Extend loan UML explicitly separates concerns of actual symbols used vs Update catalogue meaning. Many other things can be model elements: use cases, actors, Borrow journal Librarian associations, generalisation, packages, methods,... Return journal JournalBorrower An object Classifiers and instances An aspect of the UML metamodel that it's helpful to understand up front. jo : Customer An instance is to a classifier as an object is to a class: instance and classifier are more general terms. This pattern generalises: always show an instance of a classifier In the metamodel, Class inherits from Classifier, Object inherits using the same symbol as for the classifier, labelled from Instance. instanceName : classifierName. UML defines many different classifiers. E.g., UseCase and Actor are classifiers. Showing attributes and operations Compartments We saw the standard: Book a compartment for attributes title : String I I a compartment for operations, below it copiesOnShelf() : Integer borrow(c:Copy) They can be suppressed in diagrams.
    [Show full text]
  • Tram - Trng - Modeling - UML Startup - All.Pages 2 1991 Booch 91
    UML Start-Up Training UB1 Index History Overview Diagrams Use Case Diagram Sequence Diagram Activity Diagram Class Diagram Composite Structure Diagram UML State Machine Diagram This training course is designed with the intention to teach UML in not Package Diagram longer than a day. Yes UML is a complicated language with a lot of diagrams, model elements, a complex syntax and semantic; and most people claim that it takes a long time to learn that language. But: if we concentrate our efforts to the most important part of the language you will be able to become familiar with it in a day. And: use it frequently, then you’ll get the less important things by use and by reading a good book: the standard (visit the web pages from OMG and you’ll manage to download the standard, it’s free of charge). History The “OO tower” of Babel In the early Nineties there was a vast amount of competing object oriented modeling approaches together with corresponding kinds of diagrams and CASE environments which, sometimes more and sometimes less, differ from each other. Examples: Object-Oriented Analysis (OOA): Coad-Yourdon 1991 Object-Oriented Design (OOD): Booch 1991 Object Modeling Technique (OMT): Rumbaugh 1991 OO Software Engineering (OOSE): Jacobson 1992 Fusion: Coleman 1994 The Idea: Unified Modeling Language The idea of Grady Booch: A number of OO modeling dialects is replaced by a standardized language in order to bury unnecessary ditch (and religious) wars in the OO environment unite advantages of different modeling approaches relieve potential users of being spoilt for choice provide for the preconditions for data exchange between OO tools enable close integration of OO tools reduce dependencies of users of one supplier release tool manufacturers of the support of many approaches.
    [Show full text]
  • UML Diagrams
    mywbut.com UML Diagrams Overview UML was designed to be the distillation of best practices in software development. To accomplish this ambitious goal, UML provides an extensive set of diagramming tools. Because UML is such a big subject and the diagramming tools are so diverse I thought it would be helpful to give you an overview of the diagrams themselves. This chapter presents some samples of each diagram with a brief introduction describing the purpose and benefits of each diagram. As a kind of roadmap I'll use the UML groupings that divide the diagrams into packages based on their roles in the Model Management, Structural, and Behavioral aspects of system design. Model Management diagrams include Packages, which are used to represent Subsystems, Models, and more. Structural diagrams include the Class diagram, Object diagram, Composite Structure diagram, Component diagram, Deployment diagram, and the Combined Component and Deployment diagram. Behavioral diagrams include the Use Case diagram, Activity diagram, Interaction diagrams, State Machine diagram, and Protocol State Machine diagram. UML Diagrams and Work Products Each diagram reveals a unique yet overlapping view of a system. That sounds a bit strange. How can a diagram be unique yet overlap other diagrams? The uniqueness comes from the different perspective taken by each diagram. The overlap comes from the fact that all of the diagrams are looking at the same problem. The big question that usually crops up about now is, "Why do I have to use all these diagrams? Joe and Susan have always just drawn Class diagrams." This question is valid. For small, simple projects you may not need to create all these diagrams.
    [Show full text]
  • Borland Together 2008 Borland Together UML 2.1 Guide Borland Software Corporation 4 Hutton Centre Dr., Suite 900 Santa Ana, CA 92707
    Borland Together 2008 Borland Together UML 2.1 Guide Borland Software Corporation 4 Hutton Centre Dr., Suite 900 Santa Ana, CA 92707 Copyright 2009-2010 Micro Focus (IP) Limited. All Rights Reserved.Together contains derivative works of Borland Software Corporation, Copyright 2008-2010 Borland Software Corporation (a Micro Focus company). MICRO FOCUS and the Micro Focus logo, among others, are trademarks or registered trademarks of Micro Focus (IP) Limited or its subsidiaries or affiliated companies in the United States, United Kingdom and other countries. BORLAND, the Borland logo and Together are trademarks or registered trademarks of Borland Software Corporation or its subsidiaries or affiliated companies in the United States, United Kingdom and other countries. All other marks are the property of their respective owners. ii Contents Concepts...................................................................................................................5 UML 2.1 Overview......................................................................................................................5 UML 2.1 Implementation in Together .........................................................................................6 Provided and Required Interface Links of a Port........................................................................6 Required Interface...........................................................................................................7 Provided Interface...........................................................................................................8
    [Show full text]
  • Object-Oriented Data Modeling
    M13_HOFF8406_10_SE_C13.QXD 6/5/10 10:25 AM Page 13-1 CHAPTER 13 Object-Oriented Data Modeling Learning Objectives After studying this chapter, you should be able to: ᭤ Concisely define each of the following key terms: class, object, state, behavior, class diagram, object diagram, operation, encapsulation, constructor operation, query operation, update operation, class-scope operation, association, association role, multiplicity, association class, abstract class, concrete class, class-scope attribute, abstract operation, method, polymorphism, overriding, multiple classification, aggregation, and composition. ᭤ Describe the activities in the different phases of the object-oriented development life cycle. ᭤ State the advantages of object-oriented modeling vis-à-vis structured approaches. ᭤ Compare the object-oriented model with the E-R and EER models. ᭤ Model a real-world domain by using a Unified Modeling Language (UML) class diagram ᭤ Provide a snapshot of the detailed state of a system at a point in time, using a UML object diagram. ᭤ Recognize when to use generalization, aggregation, and composition relationships. ᭤ Specify different types of business rules in a class diagram. INTRODUCTION In Chapters 2 and 3, you learned about data modeling using the E-R and EER models. In those chapters, you discovered how to model the data needs of an organization using entities, attributes, and a wide variety of relationships. In this chapter, you will be introduced to the object-oriented model, which is becoming increasingly popular because of its ability to thoroughly represent complex relationships, as well as to represent data and system behavior in a consistent, integrated notation. Fortunately, most of the concepts you learned in those chapters correspond to concepts in object-oriented modeling, but the object- oriented model has even more expressive power than the EER model.
    [Show full text]