Chapter 5 Analysis PDF

Chapter 5 Analysis Outline Analysis Concepts Entity, Boundary, and Control Objects Association Multiplicity Revisited Qualified Associations Generalization Analysis Activities: From Use Cases to Objects Identifying Entity Objects Identifying Boundary Objects Identify...

Chapter 5 Analysis Outline Analysis Concepts Entity, Boundary, and Control Objects Association Multiplicity Revisited Qualified Associations Generalization Analysis Activities: From Use Cases to Objects Identifying Entity Objects Identifying Boundary Objects Identifying Control Objects Modeling Interactions between Objects: Sequence Diagrams Identifying Associations. Identifying Attributes Reviewing the Analysis Model Analysis Concepts Analysis is the process of extracting the needs of a system and what the system must do to satisfy the users’ requirements. Analysis focus on understanding the problem and its domain Main objective of analysis : capture a complete, unambiguous, and consistent picture of the requirements of the system and what the system must do to satisfy the users’ requirements and needs. By constructing models of the system that concentrate on describing WHAT the system does rather than HOW it does Analysis process of transforming a problem definition from a fuzzy set of facts to a coherent statement of a system’s requirements. Why analysis is a difficult process? Analysis is a creative activity that involves understanding the problem, its associated constraints and methods of overcoming those constraints. Three most common sources of requirements difficulties are: 1. Incomplete requirements. 2. Fuzzy descriptions. 3. Unneeded features Incomplete requirements Certain requirements necessary for successful system development are not included for variety of reasons This could include The users forgetting to identify them high cost, Politics within the business, Oversight (error, mistake, failure to notice) by the system developer Unneeded features Every additional features could affect the performance, complexity, maintenance, stability (strength) and support costs of an application Additional features and shortcuts can affect the product Analyst has 4 major tools for extracting information about a system : 1. Examination (checking, testing) of existing system documentation. 2. Interviews (meeting, discussion). 3. Questionnaire (feedback form). 4. Observation (inspection, study). Business object analysis Business object analysis is a process of understanding the system’s requirements and establishing the goals of an application The outcome of the business object analysis is to identify classes that make up the business layer and the relationships that play a role in achieving system goals To understand users’ requirements : Find out how they “use” the system, by developing use cases. USE-Case Driven OO Analysis (OOA) OOA phase of the unified approach uses actors and use cases to describe the system from users’ perspective. OOA process in the unified approach USE-Case Driven OO Analysis (OOA) OOA process consists of the following steps : 1. identify the actors : a) who is using the system ? b) who will be using the system ? ( in case of a new system ) 2. develop a simple business process model using UML activity diagram 3. develop the use case : a) what are the users doing with the system ? b) what will users be doing with the new system? (in case of a new system ) c) use cases provide comprehensive documentation of the system under study USE-Case Driven OO Analysis (OOA) 4. prepare interaction diagrams a) determine the sequence b) develop collaboration diagrams 5. classification – develop a static UML class diagram : a) identify classes b) identify relationships c) identify attributes d) identify methods e) iterate and refine : if needed, repeat the preceding steps Use-Case Driven Approach : Identifying Classes and their behaviors Use Case analysis : the process of examining use cases to discover objects and classes for the system being developed Scenarios are detailed and shown graphically in interaction diagrams Classes are grouped into packages Class diagrams are created Analysis Analysis focuses on producing model of the system, called the analysis model. Reality and Model Reality R: Real Things, People, Processes happening during some time, Relationship between things Model M: Abstractions from (really existing or only thought of) things, people, processes and relationships between these abstractions. Why models? We use models to abstract away from details in the reality, so we can draw complicated conclusions in the reality with simple steps in the model To get insights into the past or presence To make predictions about the future Analysis results in Analysis object Models and Dynamic Models Analysis object model represented by class and object diagrams Dynamic model represented by state machine and sequence diagrams Entity, Boundary, and Control objects The analysis object model consists of entity, boundary, and control objects. The Entity-Control-Boundary (ECB) pattern is a popular architectural pattern that helps organize classes based on their responsibilities within a use case. This pattern promotes modularity, reusability, and testability in your applications. often used in systems that implement the Model-View-Controller (MVC) pattern or other layered architectures. Entity Objects Entity objects represent core business concepts or real-world entities within the system. They typically correspond to the nouns of the business domain and are responsible for maintaining their state and ensuring the integrity of their data over time. Contain attributes and methods directly tied to the business domain. Usually have a unique identity (e.g., a unique ID or key) that distinguishes them. Persist over time and are stored in a database or other storage system. Example: Customer, Product, Order, Account Boundary Objects Boundary objects act as intermediaries between the system and its external entities, such as users or external systems. These objects define interfaces and manage communication. Facilitate interaction between the system and actors (users or other systems). Often tied to user interfaces Focus on input and output but do not contain business logic. Examples: User Interface, Database Gateway, Web Service Client, File System Accessor Control Objects Control objects manage the flow of data and interactions between boundary and entity objects. They encapsulate the system's behavior, handling use-case-specific logic. coordinate boundary and entity objects to fulfill use cases. Encapsulate business logic: Contain the specific rules and algorithms that govern the system's behavior. Example: LoginController, OrderProcessor , PaymentController , ReportGenerator Recommended diagrammatic convention for object type Analysis Concepts: object Types Having three type of objects leads to models that are more resilient to change. the interface of a system changes more likely than the control the control of the system change more likely than the application of domain(Entity) Analysis model for simple web Browser Analysis Concepts(Association Multiplicity Revisited) Modeling with UML the end of an association can be labeled by a set of integers called multiplicity. The multiplicity indicates the number of links that can legitimately originate from an instance of the class connected to the association end. There are three types of associations: 1. A one-to-one Association: has a multiplicity 1 on each end. A one-to- one association between two classes means that exactly one link exists between instances of each class. Analysis Concepts (Association Multiplicity Revisited) 2. A one-to-many association: has a multiplicity 1 on one end and 0..n (also represented by a star) or 1..n on the other. 3. A many-to-many association has a multiplicity 0..n or 1..n on both ends. Analysis Concepts(Qualified Associations: Reducing Multiplicity) Qualification is a technique for reducing multiplicity by using keys. Associations with a 0..1 or 1 multiplicity are easier to understand than associations with a 0..n or 1..n multiplicity. Often, in the case of a one-to-many association, objects on the “many” side can be distinguished from one another using a name. E.g Analysis Concepts(Generalization) Generalization enables to organize concepts into hierarchies. At the top of the hierarchy is a general concept and at the bottom of the hierarchy are the most specialized concepts. There may be any number of intermediate levels in between, covering more-or-less generalized concepts. Analysis Activities: From Use Cases to Objects The transition from use cases to objects is a fundamental step in object-oriented analysis. It involves identifying the key concepts and their relationships within a system, and then representing them as objects and their interactions. This process is often iterative, requiring refinement as the analysis progresses. Needs collaboration of stakeholders and domain experts to ensure the model accurately reflects the system's requirements. We can use Modeling tools like UML can help visualize and analyze the system. Analysis Activities: From Use Cases to Objects The activities that transform the use cases and scenarios produced during requirements elicitation into an analysis model. Identifying entity objects Identifying boundary objects Identifying control objects Mapping use cases to objects Identifying associations among objects Identifying object attributes Modeling generalization relationships Reviewing the analysis model Analysis Activities: From Use Cases to Objects Identifying Entity, Boundary, and Control objects from a use case involves analyzing the use case's steps and artifacts to determine which parts of the system handle data, interaction, and processes. 1. Analyze the Use Case Break down the use case into key components: Actors: Who interacts with the system? Inputs/Outputs: What data or artifacts flow through the system? Processes: What actions or decisions take place? Example: "online store" use case Actor: Customer, Payment Gateway. Input: Product details, customer information, payment information. Output: Order confirmation, receipt. Processes: Validate order, process payment, generate confirmation. Analysis Activities: From Use Cases to Objects 2. Identifying entity objects Entity Objects represent the core business concepts and data. Analyze the flow of events in each use case to identify the objects involved Look for nouns that describe domain concepts in the use case Example: From "online store ": Order: Stores details about the purchase. Product: Represents items being bought. Customer: Represents the buyer's details. Payment: Stores payment information. 3. Identifying boundary objects Boundary objects represent the system interface with the actors. Focus on the communication handle between the system and external actors (UI, APIs, or external systems). Look for inputs, outputs, and points of interaction. Example: From " online store ": OrderForm: Accepts input for products and customer details. PaymentGateway: Manages payment interaction. ConfirmationPage: Displays the order confirmation to the customer. 4. Identifying control objects Control objects coordinate processes, implement use-case-specific logic, and mediate between Entity and Boundary objects. Look for verbs or actions that describe tasks in the use case. Example: From "online store ": OrderProcessor: Handles order validation and creation. PaymentHandler: Manages payment validation and processing. NotificationService: Sends email or SMS confirmation to the customer. 5. Mapping use cases to objects Associate each step of the use case with the objects responsible for handling it. Example: "online store " Customer selects products. Boundary: OrderForm receives product selections. Entity: Product is referenced for details (price, availability). System calculates total price. Control: OrderProcessor calculates total. Entity: Product provides pricing information.  Customer provides payment details. Boundary: PaymentGateway collects payment information. System processes payment. Control: PaymentHandler validates payment details. Entity: Payment is updated with the transaction status. System confirms the order. Control: OrderProcessor finalizes the order. Boundary: ConfirmationPage displays the confirmation. Entity: Order is updated with confirmation details. Analysis Activities: Interactions Between Objects: Sequence Diagrams A sequence diagram ties use cases with objects. It shows how the behavior of a use case (or scenario) is distributed among its participating objects. They represent, however, another shift in perspective and allow the developers to find missing objects or grey areas in the system specification. Identifying Associations Associations are connections that allow objects to collaborate, exchange information, or depend on each other for specific tasks. Identifying associations among objects involves understanding the relationships and interactions required between objects to fulfill system functionality. To systematically identify associations we use the following steps Analyze the Domain Model and Use Cases Identify Direct Interactions Classify the Type of Association Represent Relationships Visually Identifying Associations 1. Analyze the Domain Model and Use Cases Review the use cases and the object model for scenarios where objects interact. Ask: What are the core relationships in the domain? How do objects depend on or communicate with each other? Example: Use Case "online store " A Customer places an Order. An Order includes multiple Products. An OrderProcessor validates the Order and processes Payment. Identifying Associations 2. Identify Direct Interactions Look for verbs or actions in the use case description that indicate a relationship between objects. Identify who interacts with whom and how. Example: OrderProcessor interacts with: Order (to retrieve order details). Product (to validate stock availability). Payment (to handle payment transactions). Identifying Associations 3. Classify the Type of Association  Determine the nature of the relationship between objects. Common association types include: Unidirectional Association Bidirectional Association Multiplicity Aggregation/Composition Identifying Associations A. Unidirectional Association One object knows about or interacts with another. Example: OrderProcessor → Payment (the OrderProcessor sends payment data to Payment). B. Bidirectional Association Both objects are aware of and interact with each other. Example: Customer ↔ Order (a Customer knows their Orders, and an Order knows its Customer). Identifying Associations C. Multiplicity Indicates how many instances of one object are associated with another. One-to-One: A Customer has one Membership. One-to-Many: A Customer places multiple Orders. Many-to-Many: An Order contains multiple Products, and a Product belongs to multiple Orders. Identifying Associations D. Aggregation/Composition Represents a "whole-part" relationship: Aggregation: Parts can exist independently of the whole. Example: A Library aggregates Books. Composition: Parts cannot exist independently of the whole. Example: An Order is composed of OrderItems. E. Dependency One object depends on another to perform its role. Example: OrderProcessor depends on Order to validate and finalize an order. Identifying Associations 4. Represent Relationships Visually Use UML Class Diagrams to illustrate associations: Lines between classes represent associations. Add labels, arrows (direction), and multiplicity indicators to clarify the relationship. Identifying Attributes Attributes represent the properties or characteristics of an object They are derived from the problem domain and use cases. Identifying attributes for objects involves determining the data that each object needs to store or manage to fulfill its responsibilities Use CRUD Analysis For each object, determine what data needs to be: Created: What information is needed when the object is instantiated? Read: What information will be accessed by other objects or processes? Updated: What data might change during the object's lifecycle? Deleted: Does any attribute require special handling when removed? Identifying Attributes Ensure attributes are relevant to the object's purpose. Avoid duplicating data across objects unless required Define Attribute Types For each attribute, determine its data type: Basic Types: Integer, Float, String, Boolean, Date, etc. Collections: Lists, Arrays, Maps, Sets (e.g., OrderItems as a list of Products). Custom Types: References to other objects (e.g., Customer in an Order). Identifying Attributes Example: Identifying Attributes for a "online store" System Objects and Their Attributes Customer Attributes: CustomerID (String), Name (String), Email (String), Address (String), Phone (String). Product Attributes: ProductID (String), Name (String), Price (Float), StockQuantity (Integer), Category (String). Order Attributes: OrderID (String), CustomerID (Reference), OrderItems (List of Products), TotalPrice (Float), OrderDate (Date), Status (String). Payment Attributes: PaymentID (String), OrderID (Reference), PaymentType (String), Amount (Float), TransactionID (String), PaymentDate (Date). Analysis Activities: Modeling Generalization Relationships Between Objects Generalization is used to eliminate redundancy from the analysis model. If two or more classes share attributes or behavior, the similarities are consolidated into a superclass. Reviewing the Analysis Model The analysis model is built incrementally and iteratively. The analysis model is seldom(rarely) correct or even complete on the first pass. Several iterations with the client and the user are necessary before the analysis model converges toward a correct specification usable by the developers for design and implementation. Documenting Analysis The RAD (Requirement Analysis Documenting ), once completed and published, will be baseline and put under configuration management. The revision history section of the RAD will provide a history of changes including the author responsible for each change, the date of the change, and brief description of the change. Thank you !