1.Assignment 1:Presentation on MethodologyClass: SYD601Student: Rick DanbyStudent Number: 2011000976Tutor: Sandra DykeSemester 2, 2012Nelson Marlborough Institute of TechnologyDue Date: 7th September 2012

2. Object Oriented Systems DevelopmentObject-oriented is an approach to systems development that proposesthe use of system objects to build new systems or rebuild old ones. Animportant goal of object-oriented development is to change the natureof traditional software development from designing and writing modelsfrom scratch to building systems through the assembly of reusablesoftware objects. Includes both data and processes with each object 3. OO Systems DevelopmentObject Oriented ApproachOO approach for systems development views an informationsystem as a collection of interacting objects that work together toaccomplish tasks.The OO system development involvesOOA Object Oriented Analysis Using an OO approach to system analysisOOD- Object Oriented Design Using an OO approach to system designOOP Object Oriented Programming Using an OO approach to programming 4. OO Systems DevelopmentOOA - Object Oriented AnalysisDefining all of the types of objects that do the work in a system and showingwhat user interactions are required to complete tasks.The result of object-oriented analysis is a description of what the system isfunctionally required to do, in the form of a conceptual model.UML diagrams can be used at this stage to help visualise the system whichcan 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 tothe right. This diagram and the rest will be covered later on in the PowerPoint in the UML section. 5. OO Systems DevelopmentOOD - Object-Oriented DesignOOD uses information and diagrams gathered from the OOA stageand also the diagrams created can be continuously grown andupdated.OOD takes care of defining all of the types of objects necessary tocommunicate with people and devices in the system, showing howthe objects interact to complete tasks, and refining the definition ofeach type of object so it can be implemented with a specificlanguage or environment.The result of object-oriented design iscreating UML sequence and class diagramsof the system. These will be covered in theUML part of the PowerPoint. 6. OO Systems DevelopmentOOP - Object-Oriented ProgrammingWriting statements in a programming language to define what each typeof object does, including the messages that the objects send to each other.Programming Languages include: 7. Objects and Classes A class is a set of objects thatshare a common structure anda common behaviour. Moresimply put theyre a blueprint,template or set of instructionswhich build a specific type ofobject.Class: defines what all objectsof the class representObjects: Objects are instancesof a classAnother example to explain thedifference is the cookie & cookiecutter. The cookie cutter is theclass or template and the cookie isthe object which is made from theclass. 8. Types of ObjectsAn object is a thing in the computersystem that can respond tomessages. Types include: User Interface - An object theuser interacts with e.g. button,menu item, text box, label Problem Domain Objects -Objects that are specific to abusiness application e.g.customer object, order object,product object 9. OO Systems Development - PrinciplesObject Oriented concepts can be broken down into four principles. Inheritance Encapsulation Polymorphism AbstractionThese will be covered in detail over the next few slides 10. OO Systems Development - PrinciplesInheritance Inheritance lets developers inherit the capabilities (methods and data) fromexisting classes to build new classes. Allowing you to use classes as standardtemplates from which other classes can be built on. A subclass is a kind ofsuperclass e.g. Magazine is a kind of book in the example below. Commonsets of attributes and methods are included in the superclass. Subclasses canthen inherit the attributes and methods of its superclass as shown below inthe diagram. Subclasses can also add in their own methods etc. which arespecific to them. The strongest reason for inheritance is code reuse.Super Class(or parent class)Sub Classes (child classes)(which are each inheritingAuthor, Title and price from thesuperclass) 11. OO Systems Development - PrinciplesEncapsulation & Information HidingEncapsulationEncapsulation makes the data and methods private within an object.That idea of encapsulation is to hide how a class does it but to allowrequesting what to do.One way to think about encapsulation is as a protective wrapper thatprevents code and data from being accessed by other code definedoutside the wrapperInformation HidingHiding the internal structure of objects, protecting them from corruptionand keeps the data safe from outside interface and misuse. 12. OO Systems Development - PrinciplesPolymorphismExample below to explainPolymorphism is closely related topolymorphism can be howpeople (objects) respond toinheritance but it is the ability ofthe same message.different objects to respond to thesame message (method) in differentways depending on their classmembership.A message can be interpreteddifferently depending on the class ofobjects.Objects belonging to different typesrespond to method, field, or propertycalls of the same name, each oneaccording to an appropriate typespecific behaviour. 13. OO Systems Development - PrinciplesAbstractionAn abstract class is a parent class that allows inheritance but can never beinstantiated. This is done when we need to only inherit from a certain class,but dont need to instantiate objects of that class. These classes are knownas "Abstract Base ClassAn abstract class holds the methodsbut the actual implementation ofthose methods is made in thederived classes. As you can see inthe diagram the abstract classShape will never be instantiated it just passes downthe methods to the actual type ofshapes square, rectangle and circle. 14. 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 manageWith each object being relatively small, self-contained and manageablereduces complexity and leads to higher quality systems which are easier tomaintain. 15. Unified Process (UP)The Unified Process is a popular iterative and incremental SoftwareDevelopment Process which has the following key features: Its component based, commonly being used to coordinate objectoriented programming projects. It uses UML - a diagrammatic notation for object oriented design The design process is anchored, and driven by use-cases which helpkeep sight of the anticipated behaviours of the system. It is architecture centric. Design is iterative and incremental - via a prescribed sequence ofdesign phases within a repeated process.It provides a way to express concepts rather than a way to draw diagrams 16. Unified Process (UP)Unified Process divides the development stages into four phases: Inception Elaboration Construction Transition 17. Unified Process Phases and Disciplines TimeThe diagram shows how the emphasis of the different disciplineschanging over the course of the project throughout the differentphases. 18. Unified Process PhasesInception: The Inception phase is where the idea is developed into a product vision.The business case for the project is built by developing a goodunderstanding of the requirements and scope of the system from what theproject stakeholders want. The feasibility of the project is assessed such as estimates of costs and theschedule of the project. UML Events tableOverall this phase establishes the feasibility of the project, creates a scope forthe project and the business case is developed. At the end of the InceptionPhase the project team will know whether or not to continue with the project. 19. Phases continuedElaboration:This phase extends further on from the previousphase 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 andimplemented.UML Diagrams created include Use Case, Conceptual diagrams and packagediagrams.By the end of this phase the basic architecture should have been producedand a plan of construction developed and agreed on. The project team willknow that they can successfully build a working system. 20. Phases continuedConstruction:The construction phase is where the project is developed from theexecutable architecture (designs) created in the Elaboration phase to anoperational system. This is where the code etc. is produced and the systemis created.By the end of this phase a working system should be available, ready fortesting and evaluation.Common UML diagrams used during this phase include Activity andSequence which show the flow of processes within the system and themessages flowing between each part. 21. Phases continuedTransition:In this phase the system is Introduced to its stakeholders andintended users. Any training or help is provided so theyunderstand the system and know how it works.In the transition phase the goal is to ensure that therequirements have been met to the satisfaction of thestakeholders.Feedback is given on the system and finally any errors orproblems are identified, corrected and improvements made. 22. 6 Main Development DisciplinesTheres 6 main disciplines which show all activities you may gothrough to produce a particular set of artefacts.The 6 main disciplines are: Business Modelling Requirements Design Implementation Testing Development Deployment 23. 6 Main Development Disciplines1. Business ModelingThe purpose of business modeling is to understand the businessenvironment . This involves: Understanding the structure and the dynamics of the organisationin the target organisation Understanding current problems in the target organisation andidentify improvement potentials To ensure that customers, end users, and developers have acommon understanding of the target organisation To develop the system requirements needed to support the targetorganisation. Understand surroundings, Create the system vision, Create businessmodels 24. Development Disciplines continued2. RequirementsThe purpose of this discipline is to document business requirementsand the scope of the project is defined. The specification documents are prepared to identify the functionalrequirements (like usage, business rules, user interface) and non-functional requirements of the project. Gather detailed information Develop user interface dialogs Evaluate requirements with users 25. Development Disciplines continued3. DesignThis is where the requirements gathered in the previous discipline areused 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 26. Development Disciplines continued4. ImplementationThis is where the building of the actual system according to thedesign is done.Implementation activities include: Build software components Acquire software components Integrate software components 27. Development Disciplines continued5. TestingTesting consists of finding bugs, ensuring that the system works as perthe design of the system and meets all requirements mentioned in thespecification 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 28. Development Disciplines continued6. DeploymentDeployment includes planning and delivering the system andsupporting documentations to the client. Also to get the systemrunning 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 dataDeployment is done in the Transition phase. 29. Development Disciplines continuedThere are 3 additional support disciplines which are Projectmanagement, Configuration & change management and Environment.Project ManagementThis includes assigning tasks, managing risks, tracking progress etc. toensure on time and within budget delivery of the system. Activitiesinclude: Finalise the system and project scope Develop the project and iteration schedule Identify project risks and confirm feasibility Monitor and control the projects plan Monitor and control communications Monitor and control risks and outstanding issues 30. Development Disciplines continuedConfiguration & change managementThis includes managing baselines of the project, accepting andmanaging change requirements, changing and delivering configurationitems and managing releases. It relates to the Requirements Design Source code ExecutablesThe two activities in this discipline Develop change control procedures Manage models and software components 31. Development Disciplines continuedEnvironmentThis includes ensuring proper tools are available whenever required.Development environment includes Available facilities Design of the workspace Forums for team communication and interactionEnvironment discipline activities Select and configure the development tools Tailor the UP development process Provide technical support services 32. UML Unified Modelling Language The Unified Modelling Language is a standard language forspecifying, visualising, constructing, and documenting the pieces ofsoftware systems.It has an important role in OO analysis and design as the UMLdiagrams are used to model the design/system. It was developedspecifically for object-oriented development.The goal of UML can be defined as a simple modelling tool to modelall possible practical systems in todays complex environment.UML diagrams fall into two categories which represent differentviews of a system. The categories are listed below and each will bedescribed in detail supported by examples over the next few slides. Static Modeling Dynamic Modeling 33. Static ModellingStatic models show the structural characteristics of the systemThis is done by using the following types of diagrams: Classes diagrams Objects diagrams Deployment diagrams Package diagrams Composite structure diagram Component diagramClass diagram is the most widely used diagram so an example of this is onthe next slide. 34. Example of a Class DiagramClass DiagramA class diagram describes the structure of a system by showing the systemsclasses, their attributes, operations (or methods), and the relationshipsamong the classes.A Basic class diagram below with the parts of the diagram identified. 35. Behaviour ModellingBehaviour modelling is used to describe and show the interaction withina system. Its can show the flow of execution within a system such as Simple object interactions Component migration Complex multithreaded system flowsBehavioural modelling shows the dynamic nature of the system in thefollowing types of diagrams: Activity diagrams Interaction diagrams Use case diagrams Collaboration/Communication diagrams 36. Examples of Behaviour Modelling diagramsUse Case DiagramA Use Case diagram is a list of stepsdefining interactions between arole/user ( "actor") and a systemto achieve a goal. The actor can bea human or an external system. Inthe diagram to the right it showshow customers, bank, staff andaccounting system ( actors) interactwith the website (system) whenpurchasing a book.The steps go from the customerentering the site and searching fora book, through to the purchase ofit. 37. Examples of BehaviourModelling diagramsActivity DiagramAn Activity diagram is basically aflow chart thats used torepresent the flow from oneactivity to another within thesystem to show the processesits going through.To the right is an example of abook being purchased by acustomer on the website andthe processes it goes through tocreate the order and send theitem to the customer. 38. Examples of Behaviour Modelling diagramsInteraction DiagramAn interaction diagram shows thedifferent classes (along the top) and thedifferent messages which are sentbetween them.The purpose of interaction diagrams areto visualise the interactive behaviour ofthe system.The sequence of the messages go fromthe top-left (beginning) of the diagramto the bottom-right (end).To the right is a basic example where theparts of the system send the messagesbetween the different classes for thepurchase of a book from the onlinewebsite by a customer. 39. All the kinds of Static ( or structure) andBehaviour Modelling diagrams 40. IntegrationOverallUnified Process is an iterative and incremental software developmentprocess . 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 developmentefforts by build diagrams that allow the team to visualise the system,identify the structure and behaviour of that system, complexity of thesoftware, construct the system, and document the decisions made alongthe way.As we can see OO Systems development uses the Unified ModellingLanguage (UML) in the analysis and design stages for modelling anddesigning the system. Many of the tasks that the Unified Process definesinvolve using UML and the UP is the process to follow for systemsdevelopment. 41. Project PlanFor this assignment the phases from the Unified Process were completing arethe Inception and Elaboration phases. 42. Inception phaseThe goal for this stage is to read the Web store Discussion document,Project Managers Decisions and the Scenario to understand exactly whatGreat Education Books wants to do with the business, establish the scopeof the project, identify risks and produce our first draft iterations of theUML diagrams.Moving into the Elaboration PhaseTo understand the process of the system a draft Events table has beencreated to show the steps that a customer would go through wheninteracting with a system to purchase a book. Version 1 of our use casediagram, domain class, activity diagrams and system sequencediagrams have been made so far. We intend to review each diagrameach week adding in changes where needed so by the final due datecomplete, full versions of the diagrams will be ready to hand in. 43. Project PlanProgress ReportsThese are to be completed by the following dates to ensure the parts arebeing 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 44. Project Plan Dates Tasks30th July 5th August Event Decomposition Table v1.6th August - 12th August Use-Case Diagram v1. Review Event Decomposition table.13th August 19th AugustDomain class Diagram v1. Review Event + Use-Case Diagrams.20th August 26th AugustActivity Diagrams v1. Review Event + Use Case + domain class diagrams.27th August 2nd SeptemberSystem Sequence Diagram v1 & State Chart Diagram v1. Review Event table, Domain class, use- case and activity diagrams.3rd September 9th SeptemberDesign Class Diagram v110th 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 Statecharts31st Sept 2nd November Review and finalise all documents and diagrams for hand in date of 2nd November.