21/1/16 1

2 Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design - Algorithms/data structures to implement each class Implementation - Translation of object classes and relationships to a particular object-oriented language time Object Model - Static structure of objects and their relationships (object diagram) Dynamic Model - Control aspects of the system (state diagrams) Functional Model - Data value transforamtions (dataflow diagrams) System

 Class Model ◦ static structure ◦ what objects are in the system? ◦ how are they related?  Dynamic Model ◦ behavioral aspects ◦ what events occur in the system ◦ when do they occur and in what order?  Functional Model ◦ data transformations ◦ “what” does the system do  Data-Oriented  Action-Oriented  Both Data and Actions 3

 the most appropriate programming structures should be based on relevant objects of the application domain.  Organize software as a collection of objects containing ◦ data structure ◦ behaviour  Build an object model of an application domain  Add implementation details to the model during design 4

StageActivity Analysis produce a document specifying what the system must do, not how to do it start with a problem statement build a real-world models of application domain concepts verify, iterate and refine the models System Design high-level design of the architectural structure to solve the problem strategy for allocating software/hardware resources to the problem organize problem components into subsystems consider performance and concurrency characteristics Object Design produce a design document using the same classes defined by analysis. Avoid using any particular programming language Objects derived from analysis may require additional details before implementation. Where necessary add: data structures algorithms Implementation transform classes into a particular hardware and software code programming language database hardware 5

 a general-purpose visual modelling language designed to specify, visualize, construct and document the artefacts of a software system  a visual modelling language that depicts the structure of the code at a level just above the code itself  independent of any particular programming language and development process  with extensibility and specialization mechanisms  that provides a formal basis for understanding the model 6

 A widely-accepted notational system for modelling object-oriented concepts.  Unified Modelling Language is intended to describe both the real-world and software 7

The Analysis phase consists of the following steps: 1. Establish Project Scope 2. Develop Context Diagram 3. Develop a simple business process model using UML activity diagram ◦ This may include modelling as-is processes and the applications that support them and would-be models of reengineered processes or implementation of the system 4. Identify the actors and use cases: ◦ Who is (or will be) using the system? 5. Develop the use cases ◦ What the users are (or will be) doing with the system? ◦ Diagram and description ◦ Explain complex uses cases using internal activity diagrams, if needed

© Lunn: Software development with UML StakeholdersProcess mapBusiness processes Requirements Analysis Use Case Diagram GUI prototype Use Case descriptions

 Functional Requirements What Systems do Inputs, Outputs, Process Non-Functional Requirements Constraints on system Performance, Volume, Security etc.

 A use case (or scenario) is a related sequence of steps, both automated and manual, for the purpose of completing a single business task ◦ Eg. Sales order approval, invoice production  Use case is not considered a functional requirement (but the story told consists of requirements)  Advantages ◦ Facilitates user involvement ◦ Gives a view of functionality from an external viewpoint ◦ Creates a tool for validating requirements & testing ◦ Provides an effective communication tool

 Does not model the system from the inside  Are not effective in capturing the non- functional requirements  Is not the same as functional decomposition  Are not inherently object oriented  Describe WHAT a system accomplished not how 12