ims1805 systems analysis n.
Skip this Video
Loading SlideShow in 5 Seconds..
IMS1805 Systems Analysis PowerPoint Presentation
Download Presentation
IMS1805 Systems Analysis

Loading in 2 Seconds...

play fullscreen
1 / 22

IMS1805 Systems Analysis - PowerPoint PPT Presentation

  • Uploaded on

IMS1805 Systems Analysis. Topic 3: Doing Analysis (continued from previous weeks). Agenda. Aim: To extend analysis and model building techniques to include the object-oriented approach To show where O-O approaches fit within the world of IS analysis

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IMS1805 Systems Analysis' - korbin

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ims1805 systems analysis

IMS1805Systems Analysis

Topic 3: Doing Analysis (continued from previous weeks)

  • Aim: To extend analysis and model building techniques to include the object-oriented approach
  • To show where O-O approaches fit within the world of IS analysis
  • To introduce some of the key elements of O-O approaches
  • To introduce the concept of the Unified Modelling Language (UML)
1 background and philosophy of object oriented analysis design and uml
1. Background and philosophy of object-oriented analysis/design and UML
  • A historical reminder:
    • The pre-analysis period
    • The process modelling period
    • The data modelling period
    • The soft systems modelling period
  • The ‘O-O revolution’ in software
  • System development as an engineering science; analysis as a formal method
  • The ‘production-line’ approach to systems development
key elements in the advance of o o analysis design techniques and uml
Key elements in the advance of O-O analysis/design techniques and UML

Using objects as a fundamental way of seeing/understanding the world

Unification & standardisation of modelling methods

The O-O World









Integrating all phases of the systems development process

Creating capabilities for automating software development

o o thinking taking a holistic view seeing systems as interacting objects
O-O thinking: Taking a holistic view - seeing systems as interacting objects
  • The separation of data from process: artificial or real? Regrettable or unavoidable?
  • Using objects and their interactions as the basis of understanding systems
  • The benefits of seeing things as objects:
    • Objects as building blocks
    • Modular design; objects as ‘black boxes’
    • Re-use/multiple use of objects
o o tools integrating analysis design and construction
O-O tools: Integrating analysis design and construction
  • Objects in software development
    • Software re-use and modularity
    • The point and click model of interface design
    • Objects and code re-usability
    • Examples - sorting routines, windows, menus, etc
  • The rise of O-O development tools - C++, Java, VB.Net, etc (O-O database?!)
  • Analysis, design and construction as an integrated continuous process
  • Using objects to unite all levels of system development
unifying standardising modelling methods the quest for a common language
Unifying/standardising modelling methods: the quest for a common language
  • Historical divide between modelling methods
  • Desire/need to unify and standardise
  • UML - Unified Modelling language
  • O-O as a source of pressure for creation of UML
  • O-O as an opportunity for creation of UML
automating software development the quest for case
Automating software development: the quest for CASE
  • Software development as a production process
  • The desire for automation of software development
  • CASE: Computer-aided software engineering
  • The CASE tools industry
  • Linking O-O integration and modularity to CASE
the o o vision
The O-O Vision

Visualisation of system as interacting objects

Analysis and specification of system as objects in UML models








language (UML)

Design and specification of system as objects in UML models

Construction of system as objects in O-O tools

some problems issues for the vision
Some problems/issues for the vision
  • Should the method be made to fit the problem or the problem be made to fit the method?
  • Is it easy (or useful/helpful) to think of things as objects?
  • Can software development be regarded as an engineering science?
  • Can software development be a production-line process?
  • How U is UML?
  • How object-oriented are UML-based O-O approaches to analysis and design?
2 fundamentals of o o thinking
2. Fundamentals of O-O thinking
  • Learning the O-O language
    • Objects and object classes
    • Object attributes and object states
    • Object hierarchies and inheritance
    • Object behaviours and methods
    • Encapsulation and information hiding
    • Polymorphism and dynamic binding
  • Note the points of similarity with non-O-O methods – same concepts, different language
  • Note the points of difference with non-O-O methods – new concepts, new ways of seeing
objects and object classes
Objects and object classes
  • System components are seen as objects which interact with one another
  • System objects can be grouped/categorised according to certain common shared features
  • Object class is a category/grouping of similar objects
  • An object class is a template, not a collection of objects; it defines the features of that object class
  • Objects belong to a particular object class if they have the features of that object class
  • (Relate to entities and instances in data modelling
object attributes and object states
Object attributes and object states
  • Attributes = information about an object
  • State = a specific combination of attribute values for an object
  • For example:
    • A ‘Student’ object may have attributes: name, ID, course, no. of credit points of study completed
    • A ‘Student’ might take one of three states:
      • ‘New student’: if no. of points completed = 0
      • ‘Current student’: if no. of points completed >0 and <144
      • Completed student’: if no. of points completed = 144
  • (Relate to attributes of entities in data modelling)
object behaviours methods and messages
Object behaviours, methods and messages
  • All objects have behaviours – things which they can do (eg a ‘student’ object would be able to perform a behaviour called ‘enrolling’)
  • All object behaviours are carried out through the use of particular methods (think of it as a specific implementation of a behaviour) (eg all student objects can enrol, but they may use different methods
  • Messages are information sent to an object which trigger its behaviours
  • (Relate to processes and data flows in process modelling)
object hierarchies and inheritance
Object hierarchies and inheritance
  • Object classes can be arranged into a hierarchy, with more general (abstract) classes at the top, broken into more specific classes at the lower levels
  • Objects at the lower levels of the hierarchy inherit all the attributes and methods of the objects above them


Current student

New student

… etc

… etc

BIS student

BComp student

encapsulation and information hiding
Encapsulation and information hiding
  • Encapsulation means that all objects combine both data and process elements (ie attributes and methods)
  • Information hiding means that although an object may encapsulate many attributes and behaviours, they are designed so that we can deal only with the aspects we are interested in – ie they are ‘black boxes’, which do things without us knowing (or caring) how
polymorphism and dynamic binding
Polymorphism and dynamic binding
  • Polymorphism means that different object classes can interpret the same message in different ways
  • Dynamic binding means that the interpretation of a message is done when the message is received by the object; therefore a programmer can write the code to send a message, without caring about how different objects may have to interpret it
  • (Both these are technical and software-based; don’t worry about them at this stage – but don’t be thrown by them if you see them in books!)
3 fundamentals of uml
3. Fundamentals of UML
  • What do we want a modelling language to do?
    • System visualisation/understanding
    • System specification
    • System construction
    • System documentation
  • Conflict between simplicity and sophistication/ range of uses
  • Conflict between standardisation and suitability for particular needs
the uml family of models
The UML ‘family’ of models
  • Grew out of the need to standardise many varied O-O diagramming methods (63 ‘official’ O-O methods identified in 1995!)
  • Initially brought together key features of three popular sets of O-O methods (version 1.0, 1996)
  • Evolved and expanded to include features of other methodologies (version 1.1, 1.3 and 1.4)
  • Enhanced and made more all-embracing (version 2.0, 2004)
  • Supported by Object Management Group (
the official uml version 2 0 model types
The Official UML Version 2.0 model types
  • Use case diagrams .. represent .. business processes
  • Activity diagrams .. represent .. flow in a use case
  • Class diagrams .. represent .. object classes an attributes
  • Sequence diagrams .. represent .. objects and their time of use
  • Interaction overview diagrams .. represent ..object interactions
  • Communication diagrams .. represent .. object-to-object messages
  • Object diagrams .. represent .. objects and their links
  • State machine diagrams .. represent .. object life-cycles (changing states)
  • Composite structure diagrams .. represent .. object behaviour
  • Component diagrams .. represent .. object libraries
  • Deployment diagrams .. represent .. system hardware
  • Package diagrams .. represent .. system sub-systems and org units
  • Timing diagrams .. represent .. timing of object interactions
the official uml version 2 0 model types1
The Official UML Version 2.0 model types
  • Note the use of diagramming forms which are not O-O!
  • Note the overlap/similarities with some process and data modelling methods
  • Note similarity in basic diagramming forms – events/sequence/things/interactions/hierarchy/etc
  • Which ones do you want to know about?
  • Which ones might I ask you about in the assignment/exam?
  • See next week’s lecture
  • O-O approaches are a different way of approaching the task of analysing a system – basic idea is the same, but we perceive different aspects of the system
  • Aim is to link analysis better with O-O implementation tools and technologies
  • Much overlap with process and data models, but greater integration of these concepts and a new language to describe it
  • UML aims to standardise and unify modelling approaches; closely linked to O-O, but in fact not purely O-O in its approach