UML WBL.pdf

Systems Analysis & Design Eleventh Edition Chapter # 10 Object-Oriented Systems Analysis and...

Systems Analysis & Design Eleventh Edition Chapter # 10 Object-Oriented Systems Analysis and Design Using UML* Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Learning Objectives (1 of 2) 10.1 Understand what object-oriented systems analysis and design is and appreciate its usefulness. 10.2 Learn the basics of CRC cards and object think. 10.3 Comprehend the concepts of unified modeling language (UML), the standard approach for modeling a system in the object-oriented world. 10.4 Explore use case modeling. 10.5 Learn how to draw and interpret activity diagrams. 10.6 Draw and explain sequence and communication diagrams. Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Learning Objectives (2 of 2) 10.7 Be able to develop class diagrams. 10.8 Enhance sequence diagrams based on the class diagrams just developed. 10.9 Enhance call diagrams in a variety of ways. 10.10 Learn how to develop statechart diagrams. 10.11 Learn the fundamentals of decision trees. 10.12 Recognize how to put UML to work. 10.13 Realize the importance of UML for modeling. Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Object-Oriented Analysis and Design (1 of 2) Works well in situations where complicated systems are undergoing continuous maintenance, adaptation, and design Objects, classes are reusable The Unified Modeling Language (UML) is an industry standard for modeling object-oriented systems. Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Object-Oriented Analysis and Design (2 of 2) Reusability – Recycling of program parts should reduce the costs of development in computer-based systems Maintaining systems – Making a change in one object has a minimal impact on other objects Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Major Topics Object-oriented concepts CRC cards and object think Unified Modeling Language Use case and other UML diagrams Packages Using UML Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Object-Oriented Concepts Objects Classes Inheritance Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Objects Persons, places, or things that are relevant to the system being analyzed May be customers, items, orders, and so on May be GUI displays or text areas on a display Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Classes Defines the set of shared attributes and behaviors found in each object in the class Should have a name that differentiates it from all other classes Instantiate is when an object is created from a class An attribute describes some property that is possessed by all objects of the class A method is an action that can be requested from any object of the class Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.1 An Example of a UML Class Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Inheritance (1 of 2) When a derived class inherits all the attributes and behaviors of the base class Reduces programming labor by using common objects easily A feature only found in object-oriented systems Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.2 A Class Diagram Showing Inheritance Car and truck are specific examples of vehicles and inherit the characteristics of the more general class vehicle. Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved CRC Cards and Object Think CRC – Class – Responsibilities – Collaborators CRC cards are used to represent the responsibilities of classes and the interaction between the classes Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.3 Four CRC Cards Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Interacting During a CRC Session Identify all the classes you can Create scenarios Identify and refine responsibilities Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved The Unified Modeling Language (UML) Concepts and Diagrams Things Relationships Diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Things Structural things are: – Classes, interfaces, use cases, and other elements that provide a way to create models – They allow the user to describe relationships Behavioral things Describe how things work – Interactions and state machines Group things – Used to define boundaries Annotational things – Can add notes to the diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Relationships (1 of 2) Structural relationships – Tie things together in structural diagrams Behavioral relationships – Used in behavioral diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Structural Relationships Dependencies Aggregations Associations Generalizations Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Behavioral Relationships Communicates Includes Extends Generalizes Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Diagrams Structural diagrams – Used to describe the relation between classes Behavioral diagrams – Used to describe the interaction between people (actors) and a use case (how the actors use the system) Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Structural Diagrams Class diagrams Object diagrams Component diagrams Deployment diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Behavioral Diagrams Use case diagrams Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Modeling Part of the unified modeling language (UML) Describes what a system does without describing how the system works A view of the system requirements Analyst works with business experts to develop requirements Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Diagram Actor – Refers to a particular role of a user of the system – Similar to external entities; they exist outside of the system Use case symbols – An oval indicating the task of the use case Connecting lines – Arrows and lines used to diagram behavioral relationships Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Actor Divided into two groups – Primary actors: ▪ Supply data or receive information from the system ▪ Provide details on what the use case should do – Supporting actors: ▪ Help to keep the system running or provide help ▪ The people who run the help desk, the analysts, programmers, and so on Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved A Use Case Always Provides Three Things An actor that initiates an event The event that triggers a use case The use case that performs the actions triggered by the event Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Relations (1 of 2) Behavioral relationships – Communicates ▪ Used to connect an actor to a use case – Includes ▪ Describes the situation in which a use case contains behavior that is common to more than one use case Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Relations (2 of 2) Behavioral relationships [continued] – Extends ▪ Describes the situation in which one use case possesses the behavior that allows the new case to handle a variation or exception from the basic use case – Generalizes ▪ Implies that one thing is more typical than the other thing Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 2.13 Four Types of UML Behavioral Relationships and the Arrows and Lines Used to Represent the Relationships Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 2.14 Examples of Use Cases and Behavioral Relationships for Student Enrollment Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Scope System scope defines its boundaries: – What is in or outside the system – Project has a budget that helps to define scope – Project has a start and an end time Actors are always outside of scope Communication lines are the boundaries and define the scope Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Developing Use Case Diagrams Review the business specifications and identify the actors involved Identify the high-level events and develop the primary use cases that describe those events and how the actors initiate them Review each primary use case to determine the possible variations of flow through the use case The context-level data flow diagram could act as a starting point for creating a use case Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 2.15 A Use Case Diagram Representing a System Used to Plan a Conference Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Developing the Use Case Scenarios The description of the use case Three main areas: – Use case identifiers and initiators – Steps performed – Conditions, assumptions, and questions Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 2.16 A Use Case Scenario is Divided into Three Sections Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Header Area Has a name and a unique ID Include application area List actors Include stakeholders Include the level Has a brief description of the use case Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Levels Use case levels describe how global or detailed the use case description is: – White (like clouds): enterprise level – Kite: business unit or department level – Blue (sea level): user goals – Indigo (or fish): functional or subfunctional – Black (or clam): most detailed Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Alternative Scenarios Extensions or exceptions to the main use case Number with an integer, decimal point, integer Steps that may or may not always be used Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Footer Area Preconditions—need to be met before use case can be performed Postconditions or the state of the system after the use case has finished Assumptions Minimal guarantee Success guarantee Outstanding issues Optional priority and risk Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Four Steps Used to Create Use Cases Use agile stories, problem definition objectives, user requirements, or a features list Ask about the tasks that must be done Determine if there are any iterative or looping actions The use case ends when the customer goal is complete Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Why Use Case Diagrams Are Helpful Identify all the actors in the problem domain Actions that need to be completed are also clearly shown on the use case diagram The use case scenario is also worthwhile Simplicity and lack of technical detail Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Reasons for Writing Use Cases Use cases effectively communicate systems requirements because the diagrams are kept simple. Use cases allow people to tell stories. Use case stories make sense to nontechnical people. Use cases do not depend on a special language. Use cases can describe most functional requirements (such as interactions between actors and applications). Use cases can describe nonfunctional requirements (such as performance and maintainability) through the use of stereotypes. Use cases help analysts define boundaries. Use cases can be traceable, allowing analysts to identify links between use cases and other design and documentation tools. Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.4 An Overall View of UML and Its Components: Things, Relationships, and Diagrams (1 of 2) UM L Category UML Elements Specific UML Details Things Structural Things Classes Interfaces Collaborations Use Cases Active Classes Components Nodes Things Behavioral Things Interactions State Machines Things Grouping Things Packages Things Annotational Notes Things Relationships Structural Dependencies Relationships Aggregations Associations Generalizations Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.4 An Overall View of UML and Its Components: Things, Relationships, and Diagrams (2 of 2) UML Category UML Elements Specific UML Details Relationships Behavioral Communicates Relationships Includes Extends Generalizes Diagrams Structural Class Diagrams Diagrams Component Diagrams Deployment Diagrams Diagrams Behavioral Use Case Diagrams Diagrams Sequence Diagrams Communication Diagrams Statechart Diagrams Activity Diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Commonly Used UML Diagrams (1 of 2) Use case diagram – Describing how the system is used – The starting point for UML modeling Use case scenario – A verbal articulation of exceptions to the main behavior described by the primary use case Activity diagram – Illustrates the overall flow of activities Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Commonly Used UML Diagrams (2 of 2) Sequence diagrams – Show the sequence of activities and class relationships Class diagrams – Show classes and relationships Statechart diagrams – Show the state transitions Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.5 An Overview of UML Diagrams Showing How Each Diagram Leads to the Development of Other UML Diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Use Case Modeling Describes what the system does, without describing how the system does it Based on the interactions and relationships of individual use cases Use case describes – Actor – Event – Use case Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.6 A Use Case Example of Student Enrollment Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.7 A Use Case Scenario is Divided into Three Sections: Identification and Initiation, Steps Performed, and Conditions, Assumptions, and Questions Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Activity Diagrams Show the sequence of activities in a process, including sequential and parallel activities, and decisions that are made Symbols – Rectangle with rounded ends – Arrow – Diamond – Long, flat rectangle – Filled-in circle – Black circle surrounded by a white circle – Swimlanes Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.8 Specialized Symbols are Used to Draw an Activity Diagram Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Creating Activity Diagrams Created by asking what happens first, what happens second, and so on Must determine what activities are done in sequence or in parallel The sequence of activities can be determined from physical data flow diagrams Can be created by examining all the scenarios for a use case Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Swimlanes Useful to show how the data must be transmitted or converted Help to divide up the tasks in a team Makes the activity diagram one that people want to use to communicate with others Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.9 This Activity Diagram Shows Three Swimlanes: Client Web Page, Web Server, and Mainframe Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Activity Diagrams and Test Plans Activity diagrams may be used to construct test plans Each event must be tested to see if the system goes to the next state Each decision must be tested Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Activity Diagrams Not Created for All Use Cases Use an activity diagram when: – It helps to understand the activities of a use case – The flow of control is complex – There is a need to model workflow – When all scenarios for a use case need to be shown Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Sequence Diagrams Illustrate a succession of interactions between classes or object instances over time Often used to show the processing described in use case scenarios Used to show the overall pattern of the activities or interactions in a use case Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.10 Specialized Symbols Used to Draw a Sequence Diagram Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.11 A Sequence Diagram for Student Admission: Sequence Diagrams Emphasize the Time Ordering of Messages Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Communication Diagrams Describes the interactions of two or more things in the system that perform a behavior that is more than any one of the things can do alone Shows the same information as a sequence diagram, but may be more difficult to read Emphasizes the organization of objects Made up of objects, communication links, and the messages that can be passed along those links Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.12 A Communication Diagram for Student Admission Communication diagrams show the same information that is depicted in a sequence diagram but emphasize the organization of objects rather than the time ordering. Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Class Diagrams (1 of 2) Show the static features of the system and do not represent any particular processing Show the nature of the relationships between classes Show data storage requirements as well as processing requirements Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Class Diagrams (2 of 2) Classes Attributes – Private – Public – Protected Methods – Standard – Custom Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.13 A Class Diagram for Course Offerings: the Filled-In Diamonds Show Aggregation and the Empty Diamond Shows a Whole-Part Relationship Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Method Overloading Including the same method (or operation) several times in a class The same method may be defined more than once in a given class, as long as the parameters sent as part of the message are different Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Types of Classes Entity classes Interface classes Abstract classes Control classes Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Entity Classes Represent real-world items The entities represented on an entity-relationship diagram Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Interface or Boundary Classes Provide a means for users to work with the system Human interfaces may be a display, window, Web form, dialogue box, touch-tone telephone, or other way for users to interact with the system System interfaces involve sending data to or receiving data from others Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Abstract Classes (1 of 2) Linked to concrete classes in a generalization/specialization relationship Cannot be directly instantiated Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Control Classes Used to control the flow of activities Many small control classes can be used to achieve classes that are reusable Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Presentation, Business, and Persistence Layers Sequence diagrams may be discussed using three layers: – Presentation layer, what the user sees, corresponding to the interface or boundary classes – Business layer, containing the unique rules for this application, corresponding roughly to control classes – Persistence or data access layer, for obtaining and storing data, corresponding to the entity classes Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Defining Messages and Methods Each message may be defined using a notation similar to that described for the data dictionary The methods may have logic defined using structured English, a decision table, or a decision tree Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.15 A Sequence Diagram for Using Two Web Pages: One for Student Information, One for Course Information Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Create Sequence Diagrams Include the actor from the use case diagram Define one or more interface classes for each actor Each use case should have one control class Examine the use case to see what entity classes are required The sequence diagram may be modified when doing detailed design Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Creating a Test Plan from a Sequence Diagram Does each method return correct results? Ensure that entity classes store or obtain the correct attribute values Verify that all JavaScript paths work correctly Ensure that the server control classes work correctly Ask, “What may fail?” Determine what to do if something can fail Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Relationships (2 of 2) The connections between classes – Associations – Whole/part Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.18 An Example of an Associative Class in Which a Particular Section Defines the Relationship between a Student and a Course Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Associations The simplest type of relationship Association classes are those that are used to break up a many-to-many association between classes An object in a class may have a relationship to other objects in the same class, called a reflexive association Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Whole/Part Relationships When one class represents the whole object, and other classes represent parts Categories – Aggregation – Collection – Composition Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Aggregation A “has a” relationship Provides a means of showing that the whole object is composed of the sum of its parts Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Collection Consists of a whole and its members Members may change, but the whole retains its identity A weak association Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Composition The whole has a responsibility for the parts, and is a stronger relationship If the whole is deleted, all parts are deleted Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.19 An Example of Whole-Part and Aggregation Relationships Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Generalization/Specialization Diagrams Generalization Inheritance Polymorphism Abstract classes Messages Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Generalization Describes a relationship between a general kind of thing and a more specific kind of thing Described as an “is a” relationship Used for modeling class inheritance and specialization General class is a parent, base, or superclass Specialized class is a child, derived, or subclass Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Inheritance (2 of 2) Helps to foster reuse Helps to maintain existing program code Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Polymorphism The capability of an object-oriented program to have several versions of the same method with the same name within a superclass/subclass relationship The subclass method overrides the superclass method When attributes or methods are defined more than once, the most specific one is used Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Abstract Classes (2 of 2) Abstract classes are general classes No direct objects or class instances, and is only used in conjunction with specialized classes Usually have attributes and may have a few methods Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.20 A Generalization/Specification Diagram is a Refined Form of a Class Diagram Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Finding Classes During interviewing or JAD sessions During facilitated team sessions During brainstorming sessions Analyzing documents and memos Examining use cases, looking for nouns Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Determining Class Methods Standard methods Examine a CRUD matrix Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Messages Used to send information by an object in one class to an object in another class Acts as a command, telling the receiving class to do something Consists of the name of the method in the receiving class, as well as the attributes that are passed with the method name May be thought of as an output or an input Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Statechart Diagrams (1 of 2) Used to examine the different states that an object may have Created for a single class – Objects are created, go through changes, and are deleted or removed Objects States Events – Signals or asynchronous messages – Synchronous – Temporal events Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Statechart Diagrams (2 of 2) Created when: – A class has a complex life cycle – An instance of a class may update its attributes in a number of ways through the life cycle – A class has an operational life cycle – Two classes depend on each other – The object’s current behavior depends on what happened previously Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.22 A Statechart Diagram Showing How a Student Progresses from a Potential Student to a Graduated Student Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Packages Containers for other UML things Show system partitioning Can be component packages Can be physical subsystems Use a folder symbol May have relationships Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Figure 10.23 Use Cases Can Be Grouped into Packages Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Putting UML to Work The steps used in UML are: – Define the use case model – Continue UML diagramming to model the system during the systems analysis phase – Develop the class diagrams – Draw statechart diagrams – Begin systems design by refining the UML diagrams – Document your system design in detail Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Summary (1 of 2) Object-oriented systems – Objects – Classes – Inheritance CRC cards UML and use case modeling Components of UML – Things – Relationships – Diagrams Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved Summary (2 of 2) UML diagrams – Use case diagrams – Activity diagrams – Sequence diagrams – Communication diagrams – Class diagrams – Statechart diagrams Using UML Copyright © 2024, 2019, 2014 Pearson Education, Inc. All Rights Reserved