My SYD601 Assignment 1 (test)

1. Assignment 1:
Presentation on Methodology
Class: SYD601
Student: Rick Danby
Student Number: 2011000976
Tutor: Sandra Dyke
Semester 2, 2012
Nelson Marlborough Institute of Technology
Due Date: 7th September 2012

3. Object Oriented Systems Development
Object-oriented is an approach to systems development that proposes
the use of system objects to build new systems or rebuild old ones. An
important goal of object-oriented development is to change the nature
of traditional software development from designing and writing models
from scratch to building systems through the assembly of reusable
software objects.
Includes both data and
processes with each object

4. OO Systems Development
Object Oriented Approach
OO approach for systems development views an information
system as a collection of interacting objects that work together to
accomplish tasks.
The OO system development involves
OOA – Object Oriented Analysis
Using an OO approach to system analysis
OOD- Object Oriented Design
Using an OO approach to system design
OOP – Object Oriented Programming
Using an OO approach to programming

5. OO Systems Development
OOA - Object Oriented Analysis
Defining all of the types of objects that do the work in a system and showing
what user interactions are required to complete tasks.
The result of object-oriented analysis is a description of what the system is
functionally required to do, in the form of a conceptual model.
UML diagrams can be used at this stage to help visualise the system which
can include different diagrams such as use-case, Activity diagrams or more.
These are used to represent the user interactions.
An example of what a use-case diagram can like is to
the right. This diagram and the rest will be covered
later on in the PowerPoint in the UML section.

6. OO Systems Development
OOD - Object-Oriented Design
OOD uses information and diagrams gathered from the OOA stage
and also the diagrams created can be continuously grown and
updated.
OOD takes care of defining all of the types of objects necessary to
communicate with people and devices in the system, showing how
the objects interact to complete tasks, and refining the definition of
each type of object so it can be implemented with a specific
language or environment.
The result of object-oriented design is
creating UML sequence and class diagrams
of the system. These will be covered in the
UML part of the PowerPoint.

7. OO Systems Development
OOP - Object-Oriented Programming
Writing statements in a programming language to define what each type
of object does, including the messages that the objects send to each other.
Programming Languages include:

8. Objects and Classes
A class is a set of objects that
share a common structure and
a common behaviour. More
simply put they’re a blueprint,
template or set of instructions
which build a specific type of
object.
Class: defines what all objects
of the class represent
Objects: Objects are instances
of a class
Another example to explain the
difference is the cookie & cookie
cutter. The cookie cutter is the
class or template and the cookie is
the object which is made from the
class.

9. Types of Objects
An object is a thing in the computer
system that can respond to
messages. Types include:
• User Interface - An object the
user interacts with e.g. button,
menu item, text box, label
• Problem Domain Objects -
Objects that are specific to a
business application e.g.
customer object, order object,
product object

10. OO Systems Development - Principles
Object Oriented concepts can be broken down into four principles.
• Inheritance
• Encapsulation
• Polymorphism
• Abstraction
These will be covered in detail over the next few slides

11. OO Systems Development - Principles
Inheritance
Inheritance lets developers inherit the capabilities (methods and data) from
existing classes to build new classes. Allowing you to use classes as standard
templates from which other classes can be built on. A subclass is a kind of
superclass e.g. Magazine is a kind of book in the example below. Common
sets of attributes and methods are included in the superclass. Subclasses can
then inherit the attributes and methods of its superclass as shown below in
the diagram. Subclasses can also add in their own methods etc. which are
specific to them. The strongest reason for inheritance is code reuse.
Super Class
(or parent class)
Sub Classes (child classes)
(which are each inheriting
Author, Title and price from the
superclass)

12. OO Systems Development - Principles
Encapsulation & Information Hiding
Encapsulation
Encapsulation makes the data and methods private within an object.
That idea of encapsulation is to hide how a class does it but to allow
requesting what to do.
One way to think about encapsulation is as a protective wrapper that
prevents code and data from being accessed by other code defined
outside the wrapper
Information Hiding
Hiding the internal structure of objects, protecting them from corruption
and keeps the data safe from outside interface and misuse.

13. OO Systems Development - Principles
Polymorphism
Example below to explain
Polymorphism is closely related to polymorphism can be how
people (objects) respond to
inheritance but it is the ability of the same message.
different objects to respond to the
same message (method) in different
ways depending on their class
membership.
A message can be interpreted
differently depending on the class of
objects.
Objects belonging to different types
respond to method, field, or property
calls of the same name, each one
according to an appropriate type
specific behaviour.

14. OO Systems Development - Principles
Abstraction
An abstract class is a parent class that allows inheritance but can never be
instantiated. This is done when we need to only inherit from a certain class,
but don’t need to instantiate objects of that class. These classes are known
as "Abstract Base Class“
An abstract class holds the methods
but the actual implementation of
those methods is made in the
derived classes. As you can see in
the diagram the abstract class
“Shape” will never be
instantiated it just passes down
the methods to the actual type of
shapes square, rectangle and circle.

15. OO Systems Development - Benefits
• Reusability
Once objects are created they can be reused in other parts of the system
which saves copying and reusing code.
• Naturalness
The way people usually think about their world, conforms with the
way people talk about their work
• Robustness
More OO languages support exception and error handling.
• Extensibility
Objects can inherit from other objects which reduces the need to
constantly “reinvent the wheel”.
• Easier to manage
With each object being relatively small, self-contained and manageable
reduces complexity and leads to higher quality systems which are easier to
maintain.

17. Unified Process (UP)
The Unified Process is a popular iterative and incremental Software
Development Process which has the following key features:
• It’s component based, commonly being used to coordinate object
oriented programming projects.
• It uses UML - a diagrammatic notation for object oriented design
• The design process is anchored, and driven by use-cases which help
keep sight of the anticipated behaviours of the system.
• It is architecture centric.
• Design is iterative and incremental - via a prescribed sequence of
design phases within a repeated process.
It provides a way to express concepts rather than a way to draw diagrams

18. Unified Process (UP)
Unified Process divides the development stages into four phases:
• Inception
• Elaboration
• Construction
• Transition

19. Unified Process Phases and Disciplines
Time
The diagram shows how the emphasis of the different disciplines
changing over the course of the project throughout the different
phases.

20. Unified Process Phases
Inception:
• The Inception phase is where the idea is developed into a product vision.
The business case for the project is built by developing a good
understanding of the requirements and scope of the system from what the
project stakeholders want.
• The feasibility of the project is assessed such as estimates of costs and the
schedule of the project.
• UML Events table
Overall this phase establishes the feasibility of the project, creates a scope for
the project and the business case is developed. At the end of the Inception
Phase the project team will know whether or not to continue with the project.

21. Phases continued…
Elaboration:
This phase extends further on from the previous
phase and focuses on the "Do-Ability" of the project
• The vision of the project is refined
• The scope is finalised
• Realistic costs and time schedule are produced
• Requirements are identified and described
• Risks are identified and the major ones are addressed
• The core architecture and functions of the system are designed and
implemented.
UML Diagrams created include Use Case, Conceptual diagrams and package
diagrams.
By the end of this phase the basic architecture should have been produced
and a plan of construction developed and agreed on. The project team will
know that they can successfully build a working system.

22. Phases continued…
Construction:
The construction phase is where the project is developed from the
executable architecture (designs) created in the Elaboration phase to an
operational system. This is where the code etc. is produced and the system
is created.
By the end of this phase a working system should be available, ready for
testing and evaluation.
Common UML diagrams used during this phase include Activity and
Sequence which show the flow of processes within the system and the
messages flowing between each part.

23. Phases continued…
Transition:
In this phase the system is Introduced to its stakeholders and
intended users. Any training or help is provided so they
understand the system and know how it works.
In the transition phase the goal is to ensure that the
requirements have been met to the satisfaction of the
stakeholders.
Feedback is given on the system and finally any errors or
problems are identified, corrected and improvements made.

24. 6 Main Development Disciplines
There’s 6 main disciplines which show all activities you may go
through to produce a particular set of artefacts.
The 6 main disciplines are:
• Business Modelling
• Requirements
• Design
• Implementation
• Testing
• Development
• Deployment

25. 6 Main Development Disciplines
1. Business Modeling
The purpose of business modeling is to understand the business
environment . This involves:
• Understanding the structure and the dynamics of the organisation
in the target organisation
• Understanding current problems in the target organisation and
identify improvement potentials
• To ensure that customers, end users, and developers have a
common understanding of the target organisation
• To develop the system requirements needed to support the target
organisation.
• Understand surroundings, Create the system vision, Create business
models

26. Development Disciplines continued…
2. Requirements
The purpose of this discipline is to document business requirements
and the scope of the project is defined.
• The specification documents are prepared to identify the functional
requirements (like usage, business rules, user interface) and non-
functional requirements of the project.
• Gather detailed information
• Develop user interface dialogs
• Evaluate requirements with users

27. Development Disciplines continued…
3. Design
This is where the requirements gathered in the previous discipline are
used to design the system.
The six activities within this discipline include:
• Design support services architecture and deployment environment
• Design the software architecture
• Design use case realisations
• Design the database
• Design the system and user interfaces
• Design the system security and controls

28. Development Disciplines continued…
4. Implementation
This is where the building of the actual system according to the
design is done.
Implementation activities include:
 Build software components
 Acquire software components
 Integrate software components

29. Development Disciplines continued…
5. Testing
Testing consists of finding bugs, ensuring that the system works as per
the design of the system and meets all requirements mentioned in the
specification documents.
Testing activities include:
 Define and conduct unit testing
 Define and conduct integration testing
 Define and conduct usability testing
 Define and conduct user acceptance testing

30. Development Disciplines continued…
6. Deployment
Deployment includes planning and delivering the system and
supporting documentations to the client. Also to get the system
running and ensure its exactly what the client wanted.
Deployment activities include:
 Obtain hardware and system software
 Package and install components
 Train users
 Convert and initialise data
Deployment is done in the Transition phase.

31. Development Disciplines continued…
There are 3 additional support disciplines which are Project
management, Configuration & change management and Environment.
Project Management
This includes assigning tasks, managing risks, tracking progress etc. to
ensure on time and within budget delivery of the system. Activities
include:
 Finalise the system and project scope
 Develop the project and iteration schedule
 Identify project risks and confirm feasibility
 Monitor and control the project’s plan
 Monitor and control communications
 Monitor and control risks and outstanding issues

32. Development Disciplines continued…
Configuration & change management
This includes managing baselines of the project, accepting and
managing change requirements, changing and delivering configuration
items and managing releases. It relates to the
 Requirements
 Design
 Source code
 Executables
The two activities in this discipline
 Develop change control procedures
 Manage models and software components

33. Development Disciplines continued…
Environment
This includes ensuring proper tools are available whenever required.
Development environment includes
 Available facilities
 Design of the workspace
 Forums for team communication and interaction
Environment discipline activities
 Select and configure the development tools
 Tailor the UP development process
 Provide technical support services

35. UML – Unified Modelling Language
The Unified Modelling Language is a standard language for
specifying, visualising, constructing, and documenting the pieces of
software systems.
It has an important role in OO analysis and design as the UML
diagrams are used to model the design/system. It was developed
specifically for object-oriented development.
The goal of UML can be defined as a simple modelling tool to model
all possible practical systems in todays complex environment.
UML diagrams fall into two categories which represent different
views of a system. The categories are listed below and each will be
described in detail supported by examples over the next few slides.
• Static Modeling
• Dynamic Modeling

36. Static Modelling
Static models show the structural characteristics of the system
This is done by using the following types of diagrams:
• Classes diagrams
• Objects diagrams
• Deployment diagrams
• Package diagrams
• Composite structure diagram
• Component diagram
Class diagram is the most widely used diagram so an example of this is on
the next slide.

37. Example of a Class Diagram
Class Diagram
A class diagram describes the structure of a system by showing the system's
classes, their attributes, operations (or methods), and the relationships
among the classes.
A Basic class diagram below with the parts of the diagram identified.

38. Behaviour Modelling
Behaviour modelling is used to describe and show the interaction within
a system. Its can show the flow of execution within a system such as
• Simple object interactions
• Component migration
• Complex multithreaded system flows
Behavioural modelling shows the dynamic nature of the system in the
following types of diagrams:
• Activity diagrams
• Interaction diagrams
• Use case diagrams
• Collaboration/Communication diagrams

39. Examples of Behaviour Modelling diagrams
Use Case Diagram
A Use Case diagram is a list of steps
defining interactions between a
role/user ( "actor") and a system
to achieve a goal. The actor can be
a human or an external system. In
the diagram to the right it shows
how customers, bank, staff and
accounting system ( actors) interact
with the website (system) when
purchasing a book.
The steps go from the customer
entering the site and searching for
a book, through to the purchase of
it.

40. Examples of BehaviourModelling diagrams
Activity Diagram
An Activity diagram is basically a
flow chart that’s used to
represent the flow from one
activity to another within the
system to show the processes
it’s going through.
To the right is an example of a
book being purchased by a
customer on the website and
the processes it goes through to
create the order and send the
item to the customer.

41. Examples of Behaviour Modelling diagrams
Interaction Diagram
An interaction diagram shows the
different classes (along the top) and the
different messages which are sent
between them.
The purpose of interaction diagrams are
to visualise the interactive behaviour of
the system.
The sequence of the messages go from
the top-left (beginning) of the diagram
to the bottom-right (end).
To the right is a basic example where the
parts of the system send the messages
between the different classes for the
purchase of a book from the online
website by a customer.

42. All the kinds of Static ( or structure) and
Behaviour Modelling diagrams

44. Integration
Overall
Unified Process is an iterative and incremental software development
process . It describes roles of participants, their responsibilities, steps,
phases, milestones in software design. Different documents, diagrams,
software components etc. are produced at each stage.
UML was designed to help project teams in software development
efforts by build diagrams that allow the team to visualise the system,
identify the structure and behaviour of that system, complexity of the
software, construct the system, and document the decisions made along
the way.
As we can see OO Systems development uses the Unified Modelling
Language (UML) in the analysis and design stages for modelling and
designing the system. Many of the tasks that the Unified Process defines
involve using UML and the UP is the process to follow for systems
development.

45. Project Plan
For this assignment the phases from the Unified Process we’re completing are
the Inception and Elaboration phases.

46. Inception phase
The goal for this stage is to read the Web store Discussion document,
Project Managers Decisions and the Scenario to understand exactly what
Great Education Books wants to do with the business, establish the scope
of the project, identify risks and produce our first draft iterations of the
UML diagrams.
Moving into the Elaboration Phase
To understand the process of the system a draft Events table has been
created to show the steps that a customer would go through when
interacting with a system to purchase a book. Version 1 of our use case
diagram, domain class, activity diagrams and system sequence
diagrams have been made so far. We intend to review each diagram
each week adding in changes where needed so by the final due date
complete, full versions of the diagrams will be ready to hand in.

47. Project Plan
Progress Reports
These are to be completed by the following dates to ensure the parts are
being completed and the projects on track to finish on time.
• Progress Report 1 : Friday 17th August - COMPLETED
• Progress Report 2 : Friday 7th September
• Progress Report 3 : Friday 28th September
• Progress Report 4 : Friday 12th October
• Progress Report 5 : Friday 26th October
• Final Report : Friday 2nd November

48. Project Plan
Dates Tasks
30th July – 5th August Event Decomposition Table v1.
6th August - 12th August Use-Case Diagram v1.
Review Event Decomposition table.
13th August – 19th August Domain class Diagram v1.
Review Event + Use-Case Diagrams.
20th August – 26th August Activity Diagrams v1.
Review Event + Use Case + domain class
diagrams.
27th August – 2nd September System Sequence Diagram v1 & State Chart
Diagram v1.
Review Event table, Domain class, use- case and
activity diagrams.
3rd September – 9th September Design Class Diagram v1
10th September- 16th September Interaction Diagrams – Sequence and
Communication Diagrams.
17th Sept – 23rd September Design Class Diagram Review/finalising.
24th Sept – 30th September Package Diagram & Design Statecharts
31st Sept – 2nd November Review and finalise all documents and diagrams
for hand in date of 2nd November.