Modified Waterfall Process Requirements Analysis Waterfall process is

Modified Waterfall Process Requirements Analysis • Waterfall process is a standard development process that only works well in certain conditions (full specification, wellstructured and well-understood domains) • Fusion addresses three phases: Analysis, Design, and Implementation Design Implementation Testing Maintenance Modified Waterfall Process

Requirements Analysis and Definition Analysis Requirements Analysis and Definition Design Implementation Testing Maintenance • Describe what the system is supposed to do in terms of functional requirements (what users can do with it) and non-functional requirements (other constraints like disk space, memory, execution time) • Establish the system services, constraints, and goals by consulting with system users • Define in a manner understandable by users and development staff • Usually in natural language, ambiguous, partially complete Requirements Analysis and Definition

Requirements Analysis Design Implementation Testing Maintenance • Formalize what the system is supposed to do • Separate the behavior of a system from its implementation • This requires viewing the system from the user's perspective rather than that of the machine. • Analysis focuses on the problem-domain and is concerned with externally visible behavior. Analysis

Requirements Design Analysis Design Implementation Testing Maintenance • Decide on how the system operations will be implemented • Runtime behavior of interacting objects • Satisfy the requirements as specified in analysis Design

Requirements Implementation Analysis Implementation Design • Map design into an effective implementation Implementation Testing Maintenance Implementation

Requirements Testing Analysis Testing Design Implementation Testing Maintenance • Integrating and testing the individual units to verify that each unit meets it specification • Integrating and testing the complete system as a whole to ensure that the software requirements have been met Testing

Requirements Maintenance Analysis Maintenance Design Implementation Testing Maintenance • Normally the longest life cycle phase • System is installed and put into practical use • Consists of correcting errors, improving implementation, and adding functionality when new requirements arise Maintenance

Fusion: Analysis Structure Fusion Analysis Object Model System Object Model Behavior Operation Model Lifecycle Model Data Dictionary Fusion: Analysis • The overall goal of Analysis is to describe what a system does rather than how • Separate the behavior of a system from its implementation Fusion Analysis • This requires viewing the system from the user's perspective rather than that of the machine. • Analysis focuses on the problem-domain and is concerned with externally visible behavior.

Fusion: Analysis Structure Fusion Structure Object Model System Object Model Behavior Operation Model Lifecycle Model Data Dictionary Structure • This phase of Analysis diagrams the entire structure of the problem domain, modeling concepts and relationships between the system, environment, as well as agents Structure • Agents are anything external to the system that can call system operations asynchronously and can receive events asynchronously • Structure is not an official part or term in Fusion, but is a useful way of understanding what the Object Model and the System Object Model do

Fusion: Analysis Structure Fusion Behavior Object Model System Object Model Behavior Operation Model Lifecycle Model Data Dictionary Behavior • This phase of Analysis models the behavior of the overall system. • It defines the input and output communication of the system. The description is in terms of Behavior events and the change of state that they cause. • Behavior is not an official part or term in Fusion, but is a useful way of understanding what the Operation Model and the Lifecycle Model do

Fusion: Analysis Structure Object Model Fusion Data Dictionary System Object Model Behavior Operation Model Lifecycle Model Data Dictionary • The Data Dictionary contains all of the terms and concepts used in all of the models. Each entry consists of the Name, Kind, and Description. Data Dictionary • Define all predicates, invariants, classes, relationships, and attributes used in the models in the Data Dictionary.

Fusion: Analysis Structure owns Fusion Object. Person Model Object Model Account System Object Model Behavior Operation Model Lifecycle Model Data Dictionary Object Model • Uses Entity-Relationship diagrams to capture all of the relevant concepts in the entire problem domain (includes environment) and the relationships between them. Fusion Object Model • These classes will not necessarily be the same classes as in the system (that’s in design) • Keep in mind the classes in these diagrams are really concepts and not really classes (in the Java or C++ sense). Don’t associate behavior with these concepts yet (that’s in design).

Fusion: Analysis Object Model Person Model owns Account Fusion System Object Structure System Object Model Behavior Operation Model Lifecycle Model Data Dictionary System Object Model • Delineates between the System and the Environment the system is running in. • Models the system, agents, and interaction with agents • The state of the system is captured here. You form the System Object Model by excluding all the classes and relationships that belong to the environment. • The System Object Model is a subset of the Object Model. These two models will contain redundant classes. • Everything inside of the dashed box is what your team will build. Everything outside of it is part of the environment. Fusion System Object Model

Fusion: Analysis Structure Object Model Fusion Operation Model System Object Model Behavior Operation Model Lifecycle Model Data Dictionary Operation Model • Describes the assumptions and effects of each system level operation Fusion Operation Model • Describes all of the possible ways the system can have its state changed by operations, and all of the events that can be output • Specifies the behavior of system operations declaratively using Operation Model Schema (operation, description, reads, changes, sends, assumes, result)

Fusion: Analysis Input Event Structure Object Model Fusion Lifecycle Model Initialization = open. #account_num. Enquiry* Enquiry = check_balance. #current_balance System Object Model Behavior State Change Operation Model Lifecycle Model Data Dictionary Input Event Followed by Output Event Lifecycle Model • Defines legal sequences of operations in system • Describes the event-based behavior of system Fusion Lifecycle Model • Sequences are defined for the entire system, not on a per class basis • Technically, the Lifecycle Model and the Operation Model are equivalent. Given one, you should be able to derive the other. The Operation Model focuses on how to change the state; the Lifecycle Model focuses on the actual state changes.