CSCI-383 Object-Oriented Programming & Design Lecture 7.

Slides:



Advertisements
Similar presentations
Chapter 11 Designing the User Interface
Advertisements

CRC Before you can build an object-oriented system, you have to define the classes (objects) that represent the problem to be solved, how the classes relate.
OBJECT-ORIENTED Design
Lecture 10 Sharing Resources. Basics of File Sharing The core component of any server is its ability to share files. In fact, the Server service in all.
© 2010 Bennett, McRobb and Farmer1 Use Case Description Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
MODULE 4 File and Folder Management. Creating file and folder A computer file is a resource for storing information, which is available to a computer.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Conversation Form l One path through a use case that emphasizes interactions between an actor and the system l Can show optional and repeated actions l.
Software Engineering COMP 201
Introduction To System Analysis and Design
Automating Tasks With Macros
Slide 6B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Lecture 4 Class Responsibility Collaboration Cards
Essentials of interaction diagrams Lecture Outline Collaborations Interaction on collaboration diagrams Sequence diagrams Messages from an object.
Object Oriented Analysis Process
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
SOS OOP Fall 2001 Object Oriented Programming in Java Week 1 Read a design Design a small program Extract a design Run a VAJ program Change that program,
Slide 7B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
Slide 6A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Use Case Analysis – continued
Chapter 13: Designing the User Interface
Exploring the Basics of Windows XP
Object-Oriented Analysis and Design
Adobe Forms THE FORM ELEMENT PANEL. Creating a form using the Adobe FormsCentral is a quick and easy way to distribute a variety of forms including surveys.
The chapter will address the following questions:
CMPT 275 Software Engineering
Objects What are Objects Observations
Introduction To System Analysis and design
Object Oriented Software Development
CMIS 470 Structured Systems Design
XP New Perspectives on Introducing Microsoft Office XP Tutorial 1 1 Introducing Microsoft Office XP Tutorial 1.
CSCI-383 Object-Oriented Programming & Design Lecture 4.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
CSCI-383 Object-Oriented Programming & Design Lecture 9.
Week 5: Business Processes and Process Modeling MIS 2101: Management Information Systems.
Introduction to Sequence Diagrams
IE 411/511: Visual Programming for Industrial Applications
Copyright © 2007, Oracle. All rights reserved. Managing Concurrent Requests.
1 CMPT 275 Phase: Design. Janice Regan, Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance.
Prepared by: Sanaz Helmi Hoda Akbari Zahra Ahmadi Sharif University of Tech. Summer 2006 An Introduction to.
CSSE 501 Object-Oriented Development. Today…  Chapter 3: Object-Oriented Design.
The Fundamentals of Using Windows 95. Windows 95 ã operating system that performs every function necessary for the user to communicate and control computer.
Introduction To System Analysis and Design
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
CSCI-383 Object-Oriented Programming & Design Lecture 13.
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
1 Analysis Extracting from Use Cases to Create Diagrams.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Lecture 14 & 15: Object- Oriented Analysis Anita S. Malik Adapted from Schach (2004) Chapter 12.
CSSE 501 Object-Oriented Development. Today…  Chapter 3: Object-Oriented Design.
Systems Analysis and Design in a Changing World, 3rd Edition
CSCI 383 Object-Oriented Programming & Design Lecture 8 Martin van Bommel.
Lecture 3 : Object Oriented Design (chapter 3. of Timothy Budd’s “Intro to OOP” book) Acknowledgement : courtesy of Prof. Timothy Budd lecture slides.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
An Introduction to Forms. The Major Steps of a MicroSoft Access Database  Tables  Queries  Forms  Macros  Reports  Modules On our road map, we are.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Lecture 3 : Object Oriented Design (chapter 3
UML - Development Process 1 Software Development Process Using UML.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Database application MySQL Database and PhpMyAdmin
Chapter 11 Following the Trail; Examining Execution Sequences
Presentation transcript:

CSCI-383 Object-Oriented Programming & Design Lecture 7

Example of generalization, extension and inclusion Example: Use-case diagram for a home security system

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd An Example, the IIKH  Imagine you are the chief software architect in a major computing firm  One day your boss rushes into your office with a specification for the next PC-based product. It is drawn on the back of a used dinner napkin, in handwriting that appears to be your boss’s  Briefly, the Intelligent Interactive Kitchen Helper will replace the box of index cards of recipes in the average kitchen

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Your Job  Your job is to develop the software that will implement the IIKH

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Abilities of the IIKH  Here are some of the things a user can do with the IIKH [identified as a result of a use-case analysis]: Browse a database of recipes Add a new recipe to the database Edit or annotate an existing recipe Plan a meal consisting of several courses Scale a recipe for some number of users Plan a longer period, say a week Generate a grocery list that includes all the items in all the menus for a period

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Scenarios  A scenario is an instance of a use case It expresses a specific occurrence of the use case  A specific actor...  At a specific time...  With specific data  Can be part of the Description field of a use case

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd An Example Scenario Alice Smith sits down at her computer and starts the IIKH. When the program begins, it displays a graphical image of a recipe box and identifies itself as the IIKH, product of IIKH incorporated. Alice presses the return button to begin.

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd An Example Scenario (cont’d) In response to the key press, Alice is given a choice of a number of options. She elects to browse the recipe index, looking for a recipe for salmon that she wishes to prepare for dinner the next day. She enters the keyword “salmon” and is shown in response a list of various recipes. She remembers seeing an interesting recipe that used dill weed as seasoning. She refines the search, entering the words “salmon” and “dill weed”. This narrows the search to two recipes.

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd An Example Scenario (cont’d) She selects the first. This brings up a new window in which an attractive picture of the finished dish is displayed, along with the list of ingredients, preparation steps, and expected preparation time. After examining the recipe, Alice determines it is not the recipe she wanted. She returns to the search result page and selects the second alternative. Examining this dish, Alice decides this is the one she had in mind. She requests a printout of the recipe, and the output is spooled to her printer. Alice selects “quit” from a program menu, and the application quits.

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Software Components  A software component is simply an abstract design entity with which we can associate responsibilities for different tasks  May eventually be turned into a class, a function, a module, or something else  A component must have a small well defined set of responsibilities  A component should interact with other components to the minimal extent possible

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd CRC Cards  Components are most easily described using CRC cards. A CRC card records the name, responsibilities, and collaborators of a component  Inexpensive, Erasable, Physical

CRC Cards (cont’d)  Responsibilities Express responsibilities as short verb phrases containing active rather than passive verbs Define what should be done, not how to do it (declarative) Include only essential information, not a great deal of detail  Collaborators A collaborator for a class or object is another class or object with which the first class communicates to carry out its responsibilities The sender of a message usually is not one of the collaborators of the receiver

CRC Cards (cont’d)  Identify an initial set of classes and objects. Can be done by performing a “grammatical parse” on scenarios or use case descriptions. Create one card for each  Identify an initial set of responsibilities and collaborators for each card. This may lead to the identification of other classes and objects  Spread the cards out on a desk or attach them to a wall  For a group project, assign one or more cards to each person in the group  Run through usage scenarios; as the flow of control passes to an object or class, bring that card to a prominent spot  As the scenarios are played out, gaps in the design are filled in. This is a form of iterative refinement

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd A Component, The Greeter  Let us return to the development of the IIKH. The first component your team defines is the Greeter. When the application is started, the Greeter puts an informative and friendly welcome window (the greeting) on the screen

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd A Component, The Greeter (cont’d)  Offer the user the choice of several different actions Casually browse the database of recipes Add a new recipe Edit or annotate a recipe Review a plan for several meals Create a plan of meals  Many of the details concerning exactly how this is to be done can be ignored for the moment

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd A Component, The Greeter (cont’d)  CRC card?

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd The Recipe Database Component  Ignoring the planning of meals for the moment, your team elects to next explore the recipe database component Must Maintain the Database of recipes Must Allow the user to browse the database Must permit the user to edit or annotate an existing recipe Must permit the user to add a new recipe

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd The Who/What Cycle  As we walk through scenarios, we go through cycles of identifying a what, followed by a who What action needs to be performed at this moment, Who is the component charged with performing the action  Every what must have a who, otherwise it simply will not happen. Sometimes the who might not be obvious at first, i.e., who should be in charge of editing a recipe?

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Postponing Decisions  Many decisions, such as the method of browsing, can be ignored for the moment, as they are entirely encapsulated within the recipe database component, and do not effect other components Scroll bars and windows? A virtual “book” with thumb-holes and flipping pages? Keywords and phrases?  Only need to note that somehow the user can manipulate the database to select a specific recipe

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Responsibilities of a Recipe  We make the recipe itself into an active data structure. It maintains information, but also performs tasks Maintains the list of ingredients and transformation algorithm Must know how to edit these data values Must know how to interactively display itself on the output device Must know how to print itself We will add other actions later (ability to scale itself, produce integrate ingredients into a grocery list, and so on)

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd The Planner Component  Returning to the greeter, we start a different scenario. This leads to the description of the Planner Permits the user to select a sequence of dates for planning Permits the user to edit an existing plan Associates with Date object

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd The Date Component  The Date component holds a sequence of meals for an individual date User can edit specific meals User can annotate information about dates (“Bob's Birthday”, “Christmas Dinner”, and so on) Can print out grocery list for entire set of meals

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd  The Meal component holds information about a single meal Allows user to interact with the recipe database to select individual recipes for meals User sets number of people to be present at meal, recipes are automatically scaled Can produce grocery list for entire meal, by combining grocery lists from individual scaled recipes The Meal Component

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd The Six Components  Having walked through the various scenarios, you team eventually decides everything can be accomplished using only six software components  You can at this point assign the different components to different programmers for development

Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd Interaction Diagrams  The picture on the previous slide captures static relationships, but not the dynamic flow of messages in a scenario. That information can be recorded by an interaction diagram