Systems Analysis & Design Methods (PDF)

Chapter 10 Object-Oriented Analysis and Modeling Using the UML McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.  Taiz University College of Engineering and Informat...

Chapter 10 Object-Oriented Analysis and Modeling Using the UML McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.  Taiz University College of Engineering and Information Technology Systems Analysis and Design Chapter 10 Object-Oriented Analysis and Modeling Using the UML 2025/2024 Fadi Mofeed, S.E [email protected] 3-2  Objectives Define object modeling and explain its benefits. Recognize and understand the basic concepts and constructs of object modeling. Define the UML and its various types of diagrams. Evolve a business requirements use-case model into a system analysis use-case model. Construct an activity diagram. Discover objects and classes, and their relationships. Construct a class diagram. 10-3  Introduction to Object Modeling Object-oriented analysis (OOA) – an approach used to 1. study existing objects to see if they can be reused or adapted for new uses 2. define new or modified objects that will be combined with existing objects into a useful business computing application OOA is concerned with defining the static structure and dynamic behavior models of the information system instead of defining data and process models, which is the goal of traditional development approaches. Object modeling – a technique for identifying objects within the systems environment and the relationships between those objects. 10-4  Introduction to the UML Unified Modeling Language (UML) – a set of modeling conventions that is used to specify or describe a software system in terms of objects. The UML does not prescribe a method for developing systems—only a notation that is now widely accepted as a standard for object modeling. 10-5  Objects & Attributes Object – something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behavior. The types of objects may include Person: employee, customer, instructor, student Place: Warehouse, office, building, room Thing: Product, vehicle, computer, videotape Event: order, payment, invoice, application, registration, reservation. Attribute – the data that represent 10-6 characteristics of interest about an object.  Objects & Object Instances Object instance – each specific person, place, thing, or event, as well as the values for the attributes of that object. 10-7  Behavior & Encapsulation Behavior – the set of things that the object can do that correspond to functions that act on the object’s data (or attributes). In object-oriented circles, an object’s behavior is commonly referred to as a method, operation, or service. Encapsulation – the packaging of several items together into one unit. Applied to an object, both attributes and behavior of the object are packaged together The only way to access or change an object’s attributes is through that object’s specific behaviors. 10-8  Object Classes Object Class – a set of objects that share common attributes and behavior. Sometimes referred to as a class. 10-9  Representing Object Classes in the UML 10-10  Inheritance Inheritance – the concept wherein methods and/or attributes defined in an object class can be inherited or reused by another object class. Also known as classification hierarchies, or “is a” relationships. 10-11  Inheritance (cont.) 10-12  Generalization/Specialization, Supertype, and Subtype Generalization/specialization – technique wherein attributes and behaviors common to several types of object classes are grouped (or abstracted) into their own class, called a supertype. Sometimes abbreviated as gen/spec. Supertype – an entity that contains attributes and behaviors that are common to one or more class subtypes. Also referred to as abstract or parent class. Subtype – an object class that inherits attributes and behaviors from a supertype class and may contain other attributes and behaviors unique to it. Also referred to as a child class and, if it exists at the lowest level of the inheritance hierarchy, as concrete class. 10-13  UML Representation of Generalization/Specialization 10-14  Object/Class Relationships Object/class relationship – a natural business association that exists between one or more objects and classes. UML refers to this line as an association The verb phrase describes the association Association is implicitly bidirectional. A CUSTOMER PLACES zero or more ORDERS. An ORDER IS PLACED BY one and only one CUSTOMER. 10-15  Association Multiplicity must be defined in both directions for every association. Must there exist an instance of CUSTOMER for each instance of ORDER? (Yes) Must there exist an instance of ORDER for each instance of CUSTOMER? (No) How many instances of ORDER can exist for each instance of CUSTOMER? (Many) How many instances of CUSTOMER can exist for each instance of ORDER? (One) An association between two object classes is 10-16 what one object “needs to know” about the other.  UML Multiplicity Notations Multiplicity – the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class. Multiplicity is essentially the same concept as cardinality in ERD 10-17  Aggregation Aggregation – a relationship in which one larger “whole” class contains one or more smaller “parts” classes. Conversely, a smaller “part” class is part of a “whole” larger class This relationship is characterized by the phrases “whole-part” and “is part of.” Multiplicity must be specified for both sides of the relationship. Aggregation was drawn with a hollow diamond, with the diamond connected to the “whole” object class. In UML 2.0 the notation for aggregation has been dropped. 10-18  Composition Composition – an aggregation relationship in which the “whole” is responsible for the creation and destruction of its “parts.” If the “whole” were to die, the “part” would die with it. Multiplicity needs to be specified only for 10-19 the “part.”  Messages Message – communication that occurs when one object invokes another object’s method (behavior) to request information or some action 10-20  Polymorphism Polymorphism – the concept that different objects can respond to the same message in different ways. Override – a technique whereby a subclass (subtype) uses an attribute or behavior of its own instead of an attribute or behavior inherited from the class 10-21 (supertype).  UML 2.0 Diagrams Diagram Description Use Case Depicts interactions between the system and external systems and users. In other words it graphically describes who will use the system and in what ways the user expects to interact with the system. The use-case narrative is used in addition to textually describe the sequence of steps of each interaction. Activity Depicts sequential flow of activities of a use case or business process. It can also be used to model logic with the system. Class Depicts the system's object structure. It shows object classes that the system is composed of as well as the relationships between those object classes. Object Similar to a class diagram, but instead of depicting object classes, it models actual object instances with current attribute values. The object diagram provides the developer with a "snapshot" of the system's object at one point in time. State Machine Models how events can change the state of an object over its lifetime, showing both the various states that an object can assume and the transitions between those states. 10-22 Composite Structure Decomposes internal structure of class, component, or use case.  UML 2.0 Diagrams (cont.) Diagram Description Sequence Graphically depicts how objects interact with each other via messages in the execution of a use case or operation. It illustrates how messages are sent and received between objects and in what sequence. Communication (Collaboration diagram in UML 1.X) Depicts interaction of objects via messages. While a sequence diagram focuses on the timing or sequence of messages, a communication diagram focuses on the structural organization of objects in a network format. Interaction Overview Combines features of sequence and activity diagrams to show how objects interact within each activity of a use case. Timing Another interaction diagram that focuses on timing constraints in the changing state of a single object or group of objects. Especially useful when designing embedded software for devices. Component Depicts the organization of programming code divided into components and how the components interact. Deployment Depicts the configuration of software components within the physical architecture of the system's hardware "nodes." Package Depicts how classes or other UML constructs are organized into 10-23 packages (corresponding to Java packages or C++ and.NET namespaces) and the dependencies of those packages.  The Process of Object Modeling 1. Modeling the functions of the system. 2. Finding and identifying the business objects. 3. Organizing the objects and identifying their relationships. 10-24  Modeling the functions of the system. Use-case modeling Document functional system requirements using business requirements use cases. The goal was to quickly document all of the business events (use cases) in order to define and validate requirements. Object modeling In performing object oriented analysis, each previously defined use case will be refined to include more and more detail. We need to evolve the business requirements use- case model into the analysis use-case model. 10-25  Construction the Analysis Use-Case Model Step 1: Identify, define, and document new actors. Resulting from business requirements use cases testing. Step 2: Identify, define, and document new use cases. The new actor discovered in step 1 leads to a new use cases. Business requirements use cases testing leads to a new use cases. Solving open issues lead to a new use cases. Assumptions lead to a new use cases. Step 3: Identify any reuse possibilities. Extract abstract use cases. Extract Extension use cases for use cases that contain complex functionality consisting of several steps. Step 4: Refine the use-case model diagram (if necessary). 10-26  Construction the Analysis Use-Case Model (cont.) Step 5: Document System Analysis Use-Case Narratives. Each use case will be refined to include more information in order to specify the system functionality in detail, and solving all open issues. The resulting system analysis use cases. System analysis use case – a use case that documents the interaction between the system user and the system. It is highly detailed in describing what is required but is free of most implementation details and constraints. Also Called system use cases. One or more system analysis use cases may evolve from a single business use case. These use cases are used by developers. 10-27  Revised System Use-Case Model Diagram 10-28  Use-Case Narrative 10-29  Use-Case Narrative (cont.) 10-30  Use-Case Narrative (cont.) 10-31  Abstract Use-Case Narrative 10-32  Modeling Use-Case Activities Activity diagram – a diagram that can be used to graphically depict the flow of a business process, the steps of a use case, or the logic of an object behavior (method). They are similar to flowcharts in that they graphically depict the sequential flow of activities of either a business process or a use case. They are different from flowcharts in that they provide a mechanism to depict activities that occur in parallel. Activity diagrams are flexible in that they can be used during both analysis and design. At least one activity diagram can be constructed for each use case. More than one can be constructed if the use case is long or contains complex logic. System analysts use activity diagrams to better understand the flow 10-33 and sequencing of the use-case steps.  Activity Diagram Notations 1. Initial node - solid circle representing the start of the process. 2. Actions – rounded rectangles representing individual steps. The sequence of actions make up the total activity shown by the diagram. 3. Flow - arrows on the diagram indicating the progression through the actions. Most flows do not need words to identify them unless coming out of decisions. 4. Decision - diamond shapes with one flow coming in and two or more flows going out. The flows coming out are marked to indicate the conditions. 5. Merge - diamond shapes with multiple flows coming in and one flow going out. This combines flows previously separated by decisions. 10-34 Processing continues with any one flow coming into the merge.  Activity Diagram Notations (cont.) 6. Fork – a black bar with one flow coming in and two or more flows going out. Actions on parallel flows beneath the fork can occur in any order or concurrently. 7. Join – a black bar with two or more flows coming in and one flow going out, noting the end of concurrent processing. All actions coming into the join must be completed before processing continues. 8. Activity final – the solid circle inside the hollow 10-35 circle representing the end of the process.  Activity Diagram with Partitions 10-36  Activity Diagram Notations (cont.) 9. Subactivity indicator – the rake symbol in an action indicates that this action is broken out in another separate activity diagram. This helps you keep the activity diagram from becoming overly complex. 10.Connector – A letter inside a circle gives you another tool for managing complexity. A flow coming into a connector jumps to the flow coming out of a connector with a matching letter. 11.Swim Lanes – Divide the activity diagram into partitions showing the actions performed by a specific class or actor. 10-37  Guidelines for Constructing Activity Diagrams Start with one initial node as a starting point. Add partitions if it is relevant to your analysis. Add an action for each major step of the use case (or each major step an actor initiates. Add flows from each action to another action, a decision point, or an end point. For maximum precision of meaning, each action should have only one flow coming in and one flow going out with all forks, joins, decisions, and merges shown explicitly. Add decisions where flows diverge with alternating routes. Be sure to bring them back together with a merge. Add forks and joins where activities are performed in parallel. End with a single notation for activity final. 10-38  Drawing System Sequence Diagrams System sequence diagram - a diagram that depicts the interaction between an actor and the system for a use case scenario. Used in the logical design phase Depicts how objects interact with each other via messages in the execution of a use case or operation. Helps identify the high-level messages that enter and exit the system. Does not include any of the alternative courses of the use case. It depicts a single scenario, a single path through the use case. 10-39  System Sequence Diagram Notations 1. Actor - the initiating actor of the use case is shown with the use case actor symbol. 2. System – the box indicates the system as a "black box" or as a whole. The colon (:) is standard sequence diagram notation to indicate a running "instance" of the system. 3. Lifelines – the dashed vertical lines extending downward from the actor and system symbols, which indicate the life of the sequence. 4. Activation bars – the bars set over the lifelines indicate period of time when participant 10-40 is active in the interaction.  System Sequence Diagram Notations (cont.) 5. Input messages - horizontal arrows from actor to system indicate the message inputs. UML convention for messages is to begin the first word with a lowercase letter and add additional words with initial uppercase letter and no space. In parentheses include parameters, following same naming convention and separated with commas. 6. Output messages – horizontal arrows from system to actor shown as dashed lines. Since they are web forms, reports, e-mails, etc. these messages do not need to use the standard notation. 10-41  System Sequence Diagram Notations (cont.) 7. Receiver Actor – other actors or external systems that receive messages from the system can be included. 8. Frame – a box can enclose one or more messages to divide off a fragment of the sequence. These can show loops, alternate fragments, or optional (opt) steps. For an optional fragment the condition shown in square brackets indicates the conditions under which the steps will be performed. 10-42  Guidelines for Constructing System Sequence Diagrams Identify which scenario of use case you will depict. Purpose is to discover messages, not to model logic. So more important to clearly communicate a single scenario. Draw a rectangle representing the system as a whole and extend a lifeline under it. Identify each actor who directly provides an input to the system or directly receives an output from the system. Extend lifelines under the actor(s). Examine use case narrative to identify system inputs and outputs. Ignore messages inside system. Draw each external message as a horizontal arrow from the actor's lifeline to the system or from the system to the actor. Label inputs according to UML convention. Add frames to indicate optional messages with conditions. Frames can also indicate loops and alternate fragments. Confirm that the messages are shown in the proper 10-43 sequence from top to bottom.  Finding and Identifying the Business Objects 1. Find the Potential Objects Review each use case to find nouns that correspond to business entities or events. 2. Select the Proposed Objects Not all nouns represent business objects. Is it a synonym of another object? Is it outside the scope of the system? Is it a role without unique behavior, or an external role? Is it unclear or in need of focus? Is it an action or an attribute that describes another object? 10-44  Partial Use-Case Narrative with Nouns Highlighted DESCRIPTION: This use case describes the event of a member submitting a new order for SoundStage products via the world wide web. The member selects the items they wish to purchase. Once they have completed their shopping, the member’s demographic information as well as their account standing will be validated. Once the products are verified as being in stock, a packing order is sent to the distribution center for them to prepare the shipment. For any product not in stock, a back order is created. On completion, the member will be sent an order confirmation. PRE-CONDITION: The individual submitting the order must be an active club member. The member must login in to the system (provide identification) to enter an order. TRIGGER: This use case is initiated when the member selects the option to enter a new order. TYPICAL COURSE Actor Action System Response OF EVENTS: Step 1: The member requests the Step 2: The system responds by displaying the option to enter a new order. catalogue of the SoundStage products. Step 3: The Member browses the Step 4: Once the member has completed their available items and selects the ones selections the system retrieves from file and they wish to purchase along with the presents the member’s demographic information quantity. (shipping and billing addresses). Step 5: The member verifies Step 6: For each product ordered, the system demographic information (shipping verifies the product availability and determines and billing addresses). If no changes an expected ship date, determines the price to be are necessary they respond charged to the member, and determines the cost accordingly (to continue). of the total order. If an item is not immediately available it indicates that the product is backordered or that it has not been released for shipping (for pre-orders). If an item is no longer available that is indicated also. The system then displays a summary of the order to the member for verification. Step 7: The member verifies the Step 8: The system checks the status of the order. If no changes are necessary member’s account. If satisfactory, the system they respond accordingly (to prompts the member to select the desired 10-45 continue). payment option (to be billed later or pay immediately with a credit card).  Potential Object List 10-46  Cleaning Up List of Candidate Objects 10-47  Proposed Object List 10-48  Organizing the Objects and Identifying their Relationships 1. Identifying Associations and Multiplicity Object Association matrix. 2. Identifying Generalization/Specialization Relationships Do any associations exist between two classes that have a one-to-one multiplicity? If so, can you say the sentence “Object X is a type of object Y” and it be true? look for classes that have common attributes and behaviors. It may be possible to combine the common attributes and behaviors into a new supertype class. 3. Identifying Aggregation and Composition Relationships 10-49 4. Prepare the Class Diagram  Object Association Matrix 10-50  Generalization/Specialization Hierarchies 10-51  Class Diagram Class diagram – a graphical depiction of a system’s static object structure, showing object classes that the system is composed of as well as the relationships between those object classes. Persistent class – a class that describes an object that outlives the execution of the program that created it. Stored permanently as in a database Transient class – a class that describes an object that is created temporarily by the program and lives only during that program’s execution. 10-52  Class Diagram (cont.) Differences between object class attributes and data entity attributes: 1. There is no need in a class diagram to include an artificial primary key attribute such as an autoincrementing ID value. 2. There is no need for foreign keys in a class diagram. 10-53  Class Diagram Refer to Figure 10-24 in text for a more 10-54 readable copy