object orientated analysis and design - contents

K. Ingram 1 November 2000

Object Orientated Analysis and Design - Contents

• When to use OO?• What is OO?• Unified Modelling Language• OO Methodologies:

– Object Modelling Technique (Rumbaugh et al, 1991)

– Objectory (Jacobson et al, 1992)– Object-oriented Process, Environment & Notation

(Graham et al, 1998)• Conclusion


When to use OO?

• For complex information systems: – by use of structures which enable the complexity

to be split down into subdivisions– by use of structures that map from real situation

through to system development.• For reliable, maintainable, modifiable information

systems.• Use OO Analysis and Design when development is

known to be in an OO language or database.• GUI-based and event-driven systems


What is OO?

• Class and Object• Generalisation and Specialisation• Message-passing• Polymorphism


OO Methodology Generations

1st Shlaer and Mellor (1988)

2nd OMT (1991), OOA (Coad and Yourdon 1991, see recommended text), Booch (1991),

Objectory (1992)

3rd Fusion, Syntropy

4thUnified Software Development Process (Jacobson et al, 1999) leading to RUP,

OPEN (1997)


Object Modelling Technique

• A framework for development proposed in 1991 by Rumbaugh et al.

• Order of most steps unimportant • Experienced developers may combine steps or

perform steps in parallel• Multiple levels of detail for each model


OMT Structure

• Analysis Phase – what the system will do in real-world terminology

• System Design Phase – High level structure of the system

• Object Design Phase – Detailed spec. for practical implementation in computer terminology (but NOT related to a specific language/database)

• See appendix 1• See appendix 2


Objectory Structure

Analysis

Testing

Construction

Test modelDesign modelConstruction model

Requirements modelAnalysis model

• 5 models produced by 3 non-sequential processes


Objectory Analysis

• Requirements Model (Functional requirements):– Mainly a Use Case model,

– Sometimes an Interface model (prototype screens)

– Sometimes a Domain Object model

• Analysis Model (gives structure to requirements):– Identify entity objects, control objects, interface objects

– Assign attributes, roles, responsibilities, associations

– Identify sub-systems dependent on coupling density.


Objectory Construction• Design Model

– each analysis object becomes a ‘block’ (i.e. a module, i.e. a UML design class)

– Possibly optimise block groupings

– Create interaction sequence diagrams for each use case

• Construction Model– Add blocks for services related to specific platform to be used

Objectory Testing• Test Model

– Verify the code


Unified Modelling Language

• Core Models:– Requirements capture – Use Case Diagrams

and Use Case Scripts– Requirements analysis – Class Diagrams

• Models derived from them:– Interaction Diagrams (Sequence or

Collaboration)– State or Activity Diagrams


Use Case Driven lifecycle(as used in OOM module)

Use Case

Diagrams

(UCD)

Use Case

Scripts

(UCS)

Class

Diagrams

And State

Diagrams

Object

Sequence

Diagrams

(OSD)


Object-oriented Process, Environment & Notation

• OPEN is a ‘process framework’ – within the framework an organisation selects the processes (Activities, Tasks, Techniques) they require to be used.

• The Activities may cover whichever life cycle phases the organisation requires – suggests Project Initiation, Requirements Engineering, Analysis and model refinement, Project Planning, Build, User Review, Consolidation


Stages

Producers

Work Units Work Products

Languages

provide organisation to the

perform produce

createevaluateiteratemaintain

are documented using

Guidelineshelp to

Components of the OPEN Process Framework


OPEN Components• Work Units: Activities, Tasks, Techniques• Producers: the roles of people/tools that created

the product or the team(s) that caused production• Work Products: the things (documents, diagrams,

models, classes, software) that the producers produce using the techniques and tasks

• Stages: phase, life cycle, milestone, ….• Languages: natural (e.g.English), modelling

(e.g.UML /OML / other), coding (e.g.Java, SQL)


OPEN Work Units

• Activities and Tasks both represent goals (what is to be done, not how).

• Tasks are smaller units than activities – the smallest project-manageable unit.

• Techniques specify how a task is to be done (e.g.CRC Cards, e.g. aggregation modelling, e.g. module coding)


OPEN Conclusion

• OPEN provides – flexibility since it is a process meta-model –

usable for large/small, critical/noncritical, long/short term projects.

– Support for full life cycle– Embedded project management framework– CMM


Conclusion

• New Methodologies are always evolving to suit new circumstances

• Not all projects match the newest circumstances

Why do most Software Development organisations use their own ‘Special Blend’ of methodologies?


Further reading on Frameworks

• Here we are talking about Software Development Frameworks not System (architecture) frameworks

• http://www.realsoftwaredevelopment.com/the-complete-list-of-software-development-frameworks-processs-methods-or-philosophies/

object orientated analysis and design - contents

Documents