UML Concepts and Methodologies Quiz

Structured Design

• Structured design aims to transform structured analysis results (like a DFD) into a structure chart.
• It provides two strategies for transforming a DFD into a structure chart: transform analysis and transaction analysis.
• Typically, one starts with a level 1 DFD, transforms it into a module representation, and then proceeds to lower-level DFDs.
• At each level, determine whether transform or transaction analysis applies.

Structure Chart

• A structure chart represents software architecture (modules, dependencies, parameter passing).
• It easily implements using programming languages.
• Focuses on module structure and interactions, not the procedural aspects.
• Basic building blocks include rectangular boxes (modules), module invocation arrows (control flow), data flow arrows (data passing), library modules (with double edges), selection (diamond symbol), repetition (loop around control flow).

Structure Chart vs. Flow Chart

• Identifying software modules from a flow chart is often difficult.
• Data interchange among modules isn't represented in a flow chart.
• Sequential ordering of tasks in a flow chart is not emphasized in a structure chart.

Example: RMS Software

• The RMS software example involves accepting input numbers, validating numbers, calculating the root mean square, and displaying results.
• Level 1 DFD identifies 'validate-input' as the afferent branch and 'write output' as the efferent branch, with 'compute-rms' as the central transform.
• Applying transform analysis steps produces the structure chart.

Transaction Analysis

• Useful for transaction-driven systems.
• Input data defines the number of transactions, which involves different processing steps for various input data items.
• Tracks data from input to output for each transaction.
• Transactions are mapped to modules in the structure chart with a tag indicating their type.
• Divides the system into transaction modules and a transaction-centre module.
• The example provided is a supermarket prize scheme.

Object Modelling Using UML

• A model captures aspects of an application, omitting irrelevant details (abstracting). Models can be graphical, textual, mathematical, or code-based.
• UML is a graphical modelling tool used to visualize, specify, construct, and document software systems. It has a set of notations and semantics.
• Important uses of models during software development include analysis, specification, code generation, design, visualization, and testing.
• UML models can be used for documentation and to develop results. The models need to match the purpose for which they are constructed.

Origin of UML

• UML emerged from several object-oriented design techniques and notations.
• A large number of object-oriented notations were used, leading to standardization efforts.
• Various methodologies (like Rumbaugh, Booch, Jacobson, Odell, Shaler & Mellor) provided principles for UML's creation.

UML Diagrams

• UML diagrams provide multiple perspectives of a system.
• UML constructs nine diagram types to display five system views: user's view, structural view, behavioral view, implementation view, and environmental view.

User's View

• Defines the functionality made available to the system's users.
• Focuses on external user-centric functionalities without showing internal details like implementation, structure, or behavior.

Structural View

• Defines the kinds of classes and objects important for understanding the system's structure and relationships.
• Also called the static model because structure does not change when implementation is altered.

Behavioral View

• How objects interact to realize the system's behavior.
• Captures the dynamic, time-dependent behavior of the system.

Implementation View

• Components/parts, and their dependencies in the system.

Environmental View

• How different components are implemented on different hardware components.

Use Case Diagrams

• Use cases represent how users interact with a system.
• A use case diagrams shows the different ways a user can interact with a system ("What users can do utilizing a system").
• Shows use cases as ellipses, enclosed within a rectangle that represents the system.
• Actors are represented by stick figures (roles played by users).
• Lines connecting actors to use cases illustrate relationships. Use cases describe user interaction with system.

Use Case Model

• Purpose of use cases is to define behavior of a system without disclosing internal structure of system.
• Mainline sequence (normal interaction) is described.
• Alternative scenarios (variations) to mainline are identified.

Text Description

• Each use case ellipse should have a text description.
• Details of how the user interacts with the system and all aspects of the use case.
• Mainline sequence, variations, system responses, and exceptional conditions are necessary.
• Should be informal, but structured, including descriptions of alternative scenarios, contact persons (people involved), actors, conditions before/after the use case runs (pre/post conditions), and references.

Non-functional Requirements

• Important constraints on design and implementation (e.g., platform, environment, response time).
• Includes domain-related error situations (e.g., invalid input fields, access rights).
• Sample dialogues or screen shots illustrating use cases.

Example: Supermarket Prize Scheme

• A detailed example of how to model a supermarket prize scheme using use cases.
• Describes specific use cases (like "register-customer").
• Explains Scenarios (like "Scenario 1: Mainline sequence").
• Displays the text description of use cases like "register-customer."

Factoring of Use Cases

• Complex use cases can be broken down into smaller, component use cases for clarity and maintainability.
• Grouping of actions that are performed by users is done in use cases.

Generalization

• Similar to subclassing/inheritance in programming.
• One use case inherits actions from a parent use case while adding a unique behavior.

Extends

• Represents optional system behaviors.
• Use cases are modified when certain conditions are met.

Organization of Use Cases

• Use cases are organized hierarchically (top-level use cases and subordinate use cases) to better understand the overall system structure.
• Shows system limits and subsystems' offered services.
• Displays the lowest level hierarchy use cases.

Example: Tic-Tac-Toe Game

• Explains how to represent use cases with a simple example utilizing use case diagram representing the actions/interactions between the user and system.