System Analysis Quiz

Chapter 5 Analysis

• Analysis is a process of extracting the needs of a system and what the system must do to satisfy user requirements.
• Analysis focuses on understanding the problem and its domain.
• The main objective of analysis is to capture complete, unambiguous, and consistent requirements of the system.
• Analysis models how the system does something rather than focusing on how the system does it.
• Analysis transforms a fuzzy problem definition into a coherent statement of a system's requirements.

Why Analysis is a Difficult Process

• Analysis is a creative activity requiring understanding the problem, its constraints, and methods of overcoming them.
• Common challenges include:
  • Incomplete requirements
  • Fuzzy descriptions
  • Unneeded features

Incomplete Requirements

• Certain requirements for successful system development are sometimes not included due to high costs, internal politics or oversight (by the developer).

Unneeded Features

• Extra features can affect system performance, complexity, maintenance, stability, and support costs.
• Unnecessary features and shortcuts can impact the product negatively.

Tools for Extracting System Information

• Examination of existing system documentation
• Interviews
• Questionnaires
• Observation

Business Object Analysis

• Business Object analysis helps understand the system's requirements and establishes application goals.
• The outcome identifies classes that construct the business layer and their relationships for achieving system goals.
• Understanding user requirements involves analyzing how users "use" the system through use cases.

USE-Case Driven OOA (OO Analysis)

• The OOA phase uses actors and use cases to describe the system from a user's perspective.
• The OOA process involves the following steps:
  • Identifying actors
  • Developing a business process model using UML Activity diagrams.
  • Developing use cases
  • Preparing interaction diagrams (sequence and collaboration diagrams)
  • Developing a static UML Class Diagram
    • Identifying classes
    • Identifying relationships
    • Identifying attributes
    • Identifying methods
  • Iterating and refining the preceding steps if necessary

Use-Case Driven Approach: Identifying Classes

• Use case analysis examines use cases to discover objects and classes for the system being developed.
• Scenarios are detailed graphically in interaction diagrams.
• Classes are grouped into packages.
• Class diagrams are constructed.

Analysis (Producing a Model)

• Analysis focuses on producing the system model called the analysis model.
• This model links requirements elicitation, functional and non-functional requirements, and other significant segments of the system design.

Reality and Model

• Reality is the real world, with real things, people, processes, and relationships, measured over time.
• A model is an abstraction of reality, simplified to focus on essential elements, and relationships between them.
• Models help gain insights into past or present realities and predict future outcomes.

Analysis Results: Models

• Analysis results in analysis object models and dynamic models.
• Analysis object models are represented by class and object diagrams.
• Dynamic models are represented by state machine and sequence diagrams.

Entity, Boundary, and Control Objects

• The analysis object model has entity, boundary, and control objects.
• The Entity-Control-Boundary (ECB) pattern organizes classes by their responsibilities within a use case.
• It promotes modularity, reusability, and testability in applications, often used in Model-View-Controller (MVC) or layered architectures.

Entity Objects

• Entity objects represent core business concepts or real-world entities within a system.
• They typically correspond to nouns in the business domain.
• They maintain their state over time and ensure data integrity.
• Entity objects contain attributes and methods directly tied to the business domain.
• Entity objects usually have unique identifiers.
• Entity objects are persistent within a storage system (e.g., database).
• Examples include Customer, Product, Order, Account.

Boundary Objects

• Boundary objects act as intermediaries between systems and their external entities (users or external systems).
• These objects define system interfaces and manage communications.
• They facilitate interactions between the system and actors.
• Often tied to user interfaces, focusing on input and output.
• Examples include User Interface, Database Gateway, a Web Service Client, or File System Accessor.

Control Objects

• Control objects manage the flow of data and interactions between boundary and entity objects.
• They encapsulate use-case-specific logic.
• They coordinate boundary and entity objects for use cases.
• They contain the rules and algorithms that govern the system's behavior.
• Examples are LoginController, OrderProcessor, PaymentController, and ReportGenerator.

Recommended Diagrammatic Conventions for Object Types

• Diagrams use circles for control objects, rectangles for boundary objects, and ovals for entity objects.

Analysis Concepts: Object Types

• Three types of objects (entity, boundary, and control) to create models that are more resilient to changes in the system interface.
• The system interface is more likely to require modifications compared to the control or application of domain objects.

Analysis Concepts: Association Multiplicity

• Modeling with UML uses integers called multiplicity to label the association end.
• Multiplicity indicates the number of permissible and legitimate links from an instance of a class.
• Three types of associations exist: one-to-one, one-to-many, many-to-many.

Analysis Concepts: Qualified Associations

• Qualification reduces multiplicity by using keys to make one-to-many associations easier to understand.
• Objects in the "many" side of the one-to-many association can be distinguished by names.

Analysis Concepts: Generalization

• Generalization organizes concepts into hierarchies.
• The top of the hierarchy is a general concept, the bottom contains specific concepts.
• Multiple intermediate levels exist between the top and bottom, representing 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.
• This process involves identifying key concepts and relationships within the system.
• Representing key concepts and relationships as objects and their interactions.
• This process is usually iterative, requiring revisions during the analysis phase.
• Collaboration with stakeholders and domain experts is necessary for accuracy.
• Modeling tools like UML can be used for better visualizations.

Analysis Activities: Key components from Use Cases

• Breaking down a use case into key components reveals actors, inputs, outputs, and processes.
• Examples include who interacts with the system ("actor"), data and artifacts passing through the system ("inputs/outputs"), and steps or actions ("processes").

Analysis Activities: Identifying Entity Objects

• Entity objects represent core business concepts and data.
• Analyzing events in use cases helps identify these objects.
• Nouns in use cases often represent domain concepts.

Analysis Activities: Identifying Boundary Objects

• Boundary objects represent the system interface with actors.
• Focuses on communication handling between systems and external actors.
• Identifies inputs, outputs, and points of interaction.

Analysis Activities: Identifying Control Objects

• Control objects coordinate processes, implement logic, and mediate between boundary and entity objects.
• Looking for verbs or actions that describe tasks in the use case helps identify control objects.

Analysis Activities: Mapping Use Cases to Objects

• Associate use case steps with the responsible objects.

Analysis Activities: Interactions Between Objects (Sequence Diagrams)

• Sequence diagrams link use cases with objects.
• They demonstrate how a use case behavior is distributed among participants.
• Sequence diagrams provide a different perspective for finding missing objects or areas needing clarification.

Identifying Associations

• Associations are connections that facilitate collaboration, information exchange, and dependencies between objects.
• Understanding relationships and interactions is important to fulfill system functionality.
• Analysis of domain model and use cases, direct interactions, classification (unidirectional, bidirectional, multiplicity), and visualization (UML Class Diagrams) steps help identify associations.

Identifying Associations: Analyzing Domain Models and Use Cases

• Analyze use cases and the object model for scenarios where objects interact.
• Establish the core relationships in the domain and how objects communicate.

Identifying Associations: Identifying Direct Interactions

• Look for verbs or actions in use cases to reveal object relationships.
• Identify who interacts with whom and how.

Identifying Associations: Classifying the Association Type

• Determine the nature of the relationship using association types such as:
  • Unidirectional Association
  • Bidirectional Association
  • Multiplicity
  • Aggregation/Composition
  • Dependency

Identifying Associations: Representing Relationships Visually

• Visualize associations using UML Class Diagrams.
• Use lines between classes to represent associations and label arrows, direction, and multiplicity indicators to clarify relationships.

Identifying Attributes

• Attributes represent object properties and characteristics.
• These are derived from the domain and use cases.
• Analyzing the different data that each object needs to maintain its responsibilities, especially when creating, reading, updating, or deleting these objects, is crucial in determining the attributes.

Identifying Attributes: Defining Attribute Types

• Define attribute data types by examining:
  • Basic types like integer, float, string, boolean, and date.
  • Collections like lists, arrays, maps, sets for complex data (e.g., lists of products).
  • Custom types that link to other objects.

Identifying Attributes: Example Attributes

• Examples of customer, product, order, and payment attributes illustrate how to identify and define attributes.

Analysis Activities: Modeling Generalization Relationships Between Objects

• Generalization eliminates redundancy in the analysis model by consolidating similarities into superclasses when two or more classes have similar attributes or behavior.

Reviewing the Analysis Model

• The analysis model is incrementally and iteratively built.
• Model refinement with client iterations helps achieve an accurate and usable specification for design and implementation.

Documenting Analysis

• Once complete, requirements analysis documents are versioned and kept under configuration management.
• Revision history records changes, including the responsible author, date, and description of changes for managing.