Introduction to OOSD– UFCFC3-30-1 Lecture Notes Week 1 Introduction and Chapter 1 and 2

Introduction to Module Team Module Tutors Dr Mazhar H Malik Contact: P.8, mazhar@gcet.edu.om Mr. Saqib Hussain Contact: L4.4, s.hussain@gcet.edu.om

Outline of Lecture Introduction Introduction to Object Oriented Programming Object Oriented System Development Life Cycle Object Oriented System Development Models To Do List

Resources Required textbook Module materials Introduction to Java Programming by Y. Daniel Liang, 10th Edition, Pearson (9th edition/international edition/brief version/pdf eBook would be OK if there are good deals but we will use 10th edition as reference). Module materials Blackboard

Resources Other resources Textbook site http://www.cs.armstrong.edu/liang/intro9e/toc.html Oracle online tutorials http://docs.oracle.com/javase/tutorial/reallybigindex.html

Module Structure 3 hours of lecture 3 hours of practical Main topics, illustrative programs 3 hours of practical Tutorials, program exercises, class tests, group assignment 6 hours of self study Textbook chapters, lecture slides, program examples, class test preparation, group assignment

Assessment Structure 5 in-class tests (50% of overall assessment) Class tests will take place as part of five consecutive practical sessions (starting from Week 3). Each class test will focus on the topics covered two weeks ago (e.g., 1st class test in Week 3 will focus on the topics that we have covered in the lecture in Week 1 and the practical sessions in Week 2). Group assignment (50%) Design, implement, test and document a substantial piece of software covering all aspects of this module. The group assignment specification will be handed out in Week 4 with submissions in on Monday in Week 11 and demos in Week 12. You would need to attend every lecture and practical session in order to learn and fully understand all the topics to be assessed in the class tests. The structure and content of the class test will be very similar to the corresponding practical exercises. You would need to do those exercises with full understanding. 7

Basic OOP Concepts and Terms

Objects Most basic component of OO design. Objects are designed to do a small, specific piece of work. Objects represent the various components of a business system

Examples of Different Object Types GUI objects objects that make up the user interface e.g. buttons, labels, windows, etc. Problem Domain objects Objects that represent a business application A problem domain is the scope of what the system to be built will solve. It is the business application. e.g. An order-entry system A payroll system A student system

Sample Problem Domain Company ABC needs to implement an order-entry system that takes orders from customers for a variety of products. What are the objects in this problem domain? Hint: Objects are usually described as nouns.

Possible Objects for this Problem Domain Customer Order Product

Classes and Objects Classes Objects Define what all objects of the class represent It is like a blueprint. It describes what the objects look like They are a way for programs to model the real world Objects Are the instances of the class

Object Attributes and Methods Classes contain two things: Fields (attributes, data members, class variables): Data items that differentiate one object of the class from another. e.g. employee name, student number Characteristics of an object that have values What are some possible attributes for the customer object? Methods (behaviors): Named, self-contained blocks of code that typically operate on the fields Describe what an object can do Can be thought of as the verbs in a problem domain What are some possible methods for the customer object?

Object Interactions and Messages Objects interact with other objects in a variety of relationships e.g. one-to-one, one-to-many Messages The means by which objects interact Example: User initiates interaction via messages to GUI objects GUI objects interact with problem domain objects via messages Problem domain objects interact with each other and GUI objects via messages GUI objects respond to user via messages

Encapsulation and Information Hiding Objects have attributes and methods combined into one unit Information Hiding Hiding the internal structure of objects, protecting them from corruption Identity Unique reference for each object Persistent objects Defined as available for use over time

Inheritance and Polymorphism One class of objects takes on characteristics of another class and extends them Superclass  subclass Generalization/specialization hierarchy Also called an inheritance hierarchy Result of extending class into more specific subclasses This is an important concept!!

Inheritance and Polymorphism literally means “many forms” in Java means using the same message (or method name) with different classes different objects can respond in their own way to the same message e.g. toString()

Learning OO Development Introducing Three-Tier Design Objects that interact in OO system are separated into three categories of classes: Problem domain classes Specific to a particular business application GUI classes Define objects that make up the UI to the application Data access classes Work with DBMS to store/retrieve object information

Unified Modeling Language (UML) Standard OOA&D modeling notation Uses model-driven approach Enables creation of graphical models of the system requirements and system design Components include Class diagrams Use Case diagrams Sequence diagrams Statecharts

SDLC Model A framework that describes the activities performed at each stage of a software development project.

Waterfall Model Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing.

Waterfall Strengths Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

Waterfall Deficiencies All requirements must be known upfront Deliverables created for each phase are considered frozen – No flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

When to use the Waterfall Model Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.

Incremental SDLC Model Construct a partial implementation of a total system Then slowly add increased functionality The incremental model prioritizes requirements of the system and then implements them in groups. Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Incremental Model Strengths Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

Incremental Model Weaknesses Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower

When to use the Incremental Model Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

Spiral SDLC Model Adds risk analysis, and 4gl RAD prototyping to the waterfall model Each cycle involves the same sequence of steps as the waterfall process model

Spiral Quadrant Determine objectives, alternatives and constraints Objectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, interface, etc.

Spiral Quadrant Evaluate alternatives, identify and resolve risks Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system development

Spiral Quadrant Develop next-level product Typical activites: Create a design Review design Develop code Inspect code Test product

Spiral Quadrant Plan next phase Typical activities Develop project plan Develop configuration management plan Develop a test plan Develop an installation plan

Spiral Model Strengths Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently

Spiral Model Weaknesses Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during non-development phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

When to use Spiral Model When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)

To Do List Before Next Lecture Read Lecture 1 slides. Selectively read those sections in Chapters 1 and 2 that cover the topics in this lecture.