Transcript Document 7213246
COS50-3 OOSD
INTRODUCTION TO OOSD
(Week 1)
April 30, 2020 Marc Conrad/Dayou Li 1
AIMS AND OBJECTIVES
• To understand the software development process, including requirement specification, analysis, design, implementation and testing. • To acquire various methodologies in software development, • To understand the process of modelling real world problems and systems using UML, • To develop skills on object oriented software development. April 30, 2020 Marc Conrad/Dayou Li 2
EXPECTION AND EXAM
• Design solutions to complex problems • Evaluate the significance of the object oriented paradigm in the production of complex software • Appraise current and future technologies in their industrial context. • Assignments and Exam: -- Assignments: 50% -- Final exam (QuestionMark): 50% April 30, 2020 Marc Conrad/Dayou Li 3
TEACHING SCHEDULE
• “Introduction” – outline OOSD, including the general process of software development, basic methodologies, preliminary on UML and Rational Rose. • “Use cases: a useful tool for capturing requirements” – basic concepts of a use case, reasons for using use cases and how to apply it to capture user requirements. • “Analysis modelling” – management of a software process, analysis models, sequence diagram and CRC card. • “OO designing” – function oriented design, object oriented design and comparison, class diagram and statechart diagram • “Software patterns” April 30, 2020 Marc Conrad/Dayou Li 4
GOOD BOOKS
• Object-Oriented Software Engineering -- a use case driven approach (revised edition) by Ivar Jacobson • UML Distilled (2nd Edition) by Martin Fowler • Software Engineering (4th Edition) by Ian Sommerville • Developing Applications with Java and UML by Paul R and Reed Jr • An Introduction of Object Oriented Programming with Java (2nd Edition) by C Thomas Wu April 30, 2020 Marc Conrad/Dayou Li 5
SOFTWARE PROCESS
• A software Process:
not
just coding • London Ambulance Service (LAS) -- a true disaster of software engineering. - - Time: from early 1980’s to 1992, Total cost: £7.5 million, -- Result: abandoned April 30, 2020 Marc Conrad/Dayou Li 6
SOFTWARE PROCESS (Cont’d)
• LAS manual system: April 30, 2020 Marc Conrad/Dayou Li 7
SOFTWARE PROCESS (Cont’d)
LAS required system: Auto Call Distributor Mapping system Computer aided dispatch System Auto Vehicle Location System Radio Interface System April 30, 2020 Marc Conrad/Dayou Li 8
SOFTWARE PROCESS (Cont’d)
• Things went wrong from very beginning: -- End-user hostility -- lack of consultation, -- Official project issue report process was not followed, -- Problems were left in later stages, ignored and programmed, -- Hidden and newly introduced bugs, -- Test team had no knowledge about changes. • Lessons was taught -- Software development is like other engineering processes, -- The process must be strictly followed.
April 30, 2020 Marc Conrad/Dayou Li 9
METHODOLOGIES
• Waterfall approach -- requirement, design, coding and test stages, one after another, • Exploratory programming -- working system plus improvement, • Prototyping -- establishing system requirements plus re-implementation, • Formal transformation -- transforming specifications into program, • System assembly from reusable components . April 30, 2020 Marc Conrad/Dayou Li 10
WHATERFALL MODEL
Requirement Specification Analysis Design Implemen tation Testing 11 April 30, 2020 Marc Conrad/Dayou Li
WHATERFALL MODEL (Cont’d)
• Requirement specification -- collecting and understanding clients’ requirements.
• Analysis -- establishing system’s services, constraints and goals by consultation with system’s users. • Design -- establishing an overall system architecture, including program units and interface between those units, • Implementation -- realising programs or program units and verifying that each unit meets its specification, April 30, 2020 Marc Conrad/Dayou Li 12
WHATERFALL MODEL (Cont’d)
• integration -- integrating the individual program units are testing as a complete system to ensure the the system satisfy users requirements. • Testing -- verification (Does the system work right?) and validation (Do we build up a right system?). 13 April 30, 2020 Marc Conrad/Dayou Li
WHATERFALL MODEL (Cont’d)
User requirement Analysis Design Implemen tation Testing April 30, 2020 Marc Conrad/Dayou Li 14
CRISIS ARE STILL WITH US
• 31% of project will get cancelled before they ever get complete • 88% of all projects are over schedule, over budget or both • for every 100 projects started, there are 94 restarts • Average cost overun is 189% of original estimate • Average time overun is 222% of original estimate April 30, 2020 Marc Conrad/Dayou Li 15
CRISIS ARE STILL WITH US
• Causes: -- Incomplete requirements -- 13% -- Lack of user involvement -- 12.4% -- Lack of resources -- 10.6% -- Unreasonable expectations -- 9.9% -- No management support -- 9.3% -- Specification changes -- 8.7% -- Lack of planning -- 8.1% -- No longer needed -- 7.5% • Reason and solution: -- Methodologies are difficult to follow -- Modelling language for implement the methods April 30, 2020 Marc Conrad/Dayou Li 16
INTRODUCTION TO UML
•
UML -- Unified Modelling Language
• It would help us (software engineers) to modelling real world problems and systems, e.g. -- Use Cases: to capture requirements -- Analysis modelling: to establish system specifications -- Design modelling: to design a system -- Package: large systems management April 30, 2020 Marc Conrad/Dayou Li 17
INTRODUCTION TO UML
• It allows implementation-independent specification of: -- user/system interactions (required behaviors) -- partitioning of responsibility (OO) -- integration with larger or existing systems -- data flow and dependency -- operation orderings (algorithms) -- concurrent operations April 30, 2020 Marc Conrad/Dayou Li 18
CONTENTS OF UML
• Use cases, • Interaction diagrams (Sequence Diagram, CRC, Collaboration Diagram) • Class Diagram (aggregations, composites, interfaces and realisations) • Package • Activity Diagram • State Diagram, State Chart, and Data Flow Diagram April 30, 2020 Marc Conrad/Dayou Li 19
RATIONAL ROSE
• Rose is one of products from Rational Software. • It is an expensive CASE (Computer-Aided Software Engineering) tool for object-oriented modeling.
• Based on UML (more or less).
• It provides semantics (a ‘compiler’) for UML.
• It has a reasonably intuitive GUI similar to standard drawing programs, like Illustrator, and is available for Windows and other platforms.
• It makes creating and maintaining your UML diagrams easier (or at least more consistent).
• Has many bizarre features, including generation of C++ (and other) code from your diagrams.
April 30, 2020 Marc Conrad/Dayou Li 20
RATIONAL ROSE (Cont’d)
• You can visit their website: http://www.rational.com/ • Getting the Evaluation copy (limited to 15 days): http://www.rational.com/tryit/rose/index.jsp
• Rational Rose is also Installed in our CIS Lab (Room 015) • Our practicals will be based on the software. 21 April 30, 2020 Marc Conrad/Dayou Li
RATIONAL ROSE (Cont’d)
• Why do we need the Rational Rose? -- We use it to create a series of
models
for all the steps of OOSD -- Each model contains views, diagrams, and specifications to visualise and manipulate the elements in the model -- There are many views of each underlying element - Every “object” in the design is represented once in the Rose “model” -- Rose maintains a consistent semantic representation in the “model” April 30, 2020 Marc Conrad/Dayou Li 22
RATIONAL ROSE (Cont’d)
• What does Rational Rose look like? -- Standard toolbar -- Diagram toolbar -- Browser: a drop-down list of things in your model -- Documentation window: where you can add notes to a thing in your model -- Diagram windows: where you draw your pictures -- Specifications -- Status bar April 30, 2020 Marc Conrad/Dayou Li 23
Standard Toolbar Browser Documen tation Window Status Bar
April 30, 2020
Diagram Toolbar Diagram Window
Marc Conrad/Dayou Li 24
SUMMARY
• Credit Scheme • Software process • Introduction of UML • Introduction to Rational Rose April 30, 2020 Marc Conrad/Dayou Li 25
COS50-3 OOSD
REQUIREMENT MODEL: USE CASE DIAGRAM
(Week 2)
April 30, 2020 Marc Conrad/Dayou Li 26
MODELLING
System development is model building
• Complexity -- hard to handle many requirements at the same time • Modelling -- an organised way to handle requirements • Models -- standard representations so that everyone can follow • Various types of models -- for different purposes and stages in software development April 30, 2020 Marc Conrad/Dayou Li 27
MODELLING (Cont’d)
Various types of models
• Requirement model: •capture functional/user’s requirements • Analysis model: •give the system a robust and changeable structure • Design model: •adopt and refine the structure to the current implementation environment • Implementation model: •implement the system • Test model: April 30, 2020 Marc Conrad/Dayou Li •verify the system 28
MODELLING (Cont’d)
Architecture of a modelling language
Model architecture -- a set of modelling language, notation or modelling technique. It contains: • Syntax -- how it looks • Semantics -- what it means • Pragmatics -- heuristics and rules of thumb for using it April 30, 2020 Marc Conrad/Dayou Li 29
REQUIREMENT MODEL
What are requirements?
• Statements of a customer/end-user’s needs and expectations • Descriptions of essential characteristics of the customer/end-user,s goal • Requirements should be problem based and not describe the solution April 30, 2020 Marc Conrad/Dayou Li 30
USE CASE DIAGRAM
Syntax:
• Actor - • Use case - • Relationship - • System border - April 30, 2020 Marc Conrad/Dayou Li 31
Rational Rose & Use case diagrams
Paul goes to Lecture <
April 30, 2020 Marc Conrad/Dayou Li 32
USE CASE DIAGRAM (Cont’d)
Semantics:
• An actor represents anything that is
outside
of the system and that needs to
exchange
information with the system.
-- An individual person (end-user) -- A group of people -- An individual can play different roles -- A machine - ….. April 30, 2020 Marc Conrad/Dayou Li 33
USE CASE DIAGRAM (Cont’d)
• A use case represents a special sequence of
events triggered
by an actor.
• Example: making an initialisation process user friendly.
• being willing to initialise • choosing a variable • assigning a “wrong” value • assigning a “correct” value
A use case
April 30, 2020 • sending a list of variables • giving the range of the variable • giving a warning signal • giving acknowledgement Marc Conrad/Dayou Li 34
USE CASE DIAGRAM (Cont’d)
• Relationship represents information exchange between an actor and a use case and between two use cases. • We have different types of relationship existing between an actor and a use case and between two use cases.
• Ordinary relationship: showing that there is a relationship between an actor and a use case or between two use cases. • We use symbol relationship.
to represent this type of April 30, 2020 Marc Conrad/Dayou Li 35
USE CASE DIAGRAM (Cont’d)
•
Extend
relationship exists between
two similar use cases
where the second one has some extra activities, that is the activities of the first use case are extended in the second one. • The first use case sends information to the second use case to invoke the extra activities. • Terms: -- the first use case: base use case, -- the second use case: extending use case -- the information: extension point. April 30, 2020 Marc Conrad/Dayou Li 36
USE CASE DIAGRAM (Cont’d)
• Example -- think about an Internet search engine. You type in key words and press “submit”. This will trigger a sequence of activities happening in a search engine.
-- If there is no spelling mistake in the key words, the search engine will go ahead to search for items.
--If there is a spelling mistake, the search engine will ask you to confirm the key word.
search
<
confirm
Extension point: spelling info April 30, 2020 Marc Conrad/Dayou Li 37
USE CASE DIAGRAM (Cont’d)
•
Generalisation
relationship exists between two similar use cases. The base use case includes basic activities and the second use case contains the alternative activities. Both use cases handle the
same
thing but the base use case deals with the general situation and the second one deals with special cases. • Generalisation relationship says that alternatives exist. April 30, 2020 Marc Conrad/Dayou Li 38
USE CASE DIAGRAM (Cont’d)
• Example -- Suppose in an Internet search engine, we have designed two sequences of searching activities: one sequence of activities is the normal search and the other one is intelligent search which is for academy. -- So we have two use cases corresponding to these two sequences of activities: one contains the normal search activities (called base use case) and the other contains the intelligent search activities. -- Both handle the request of search, but the second one deal with special request -- academic request. April 30, 2020
Normal search
Marc Conrad/Dayou Li
Intelligent search
39
USE CASE DIAGRAM (Cont’d)
• If two or more use cases have a chunk of same activities, we can create a new use case that contains this chunk of activities. The relation from the
original use cases to the new one
is the
Include
relationship, which means that the original use cases involve the activities of the new use case. They share the activities of the new use case.
• By having the new use case and the include relationship, we can avoid the repeating of the same activities in different use cases. April 30, 2020 Marc Conrad/Dayou Li 40
USE CASE DIAGRAM (Cont’d)
• Example: -- Both the normal and the intelligent search engines need to read the key words you typed in. -- The activity of reading key words can then be picked up from the two use cases and placed into a new use case.
normal intelligent New case
Marc Conrad/Dayou Li April 30, 2020 41
USE CASE DIAGRAM (Cont’d)
Pragmatics:
• Identify system border -- Which action should be taken by actors and which by system? This is vital important. • Identify actor(s) - What are “objects”
outside
of the system which want to exchange information with the system? Can we classify them? • Identify use case(s) -- What are the main tasks of each actor? An use case should link to a main task and contain a complete course of events related to the task. • Add relationship -- We need to pay extra attention on those between use cases. April 30, 2020 Marc Conrad/Dayou Li 42
CASE STUDY
A recycling machine
• System description: The system controls a recycling machine for returnable bottles, cans and crates. The machine can be used by several
customers
at the same time and each customer can return all three types of item on the same occasion. April 30, 2020 Marc Conrad/Dayou Li 43
CASE STUDY (Cont’d)
The system has to check , for each item, what type has been returned. The system will register how many items each customer returns and when the customer asks for a receipt, the system will print out what was deposited , the value of the returned items and the total return sum that will be paid to the customer. An
operator
also uses the system. He asks for a printout of the total number of items that have been deposited at the end of each day. He has right to change the deposit values of the items through a console. When anything wrong with the machine, the operator will be called by a special alarm signal. April 30, 2020 Marc Conrad/Dayou Li 44
CASE STUDY (Cont’d)
• Identify actors: customer April 30, 2020 Marc Conrad/Dayou Li operator 45
CASE STUDY (Cont’d)
• Identify use cases: Generating daily report Returning items April 30, 2020 Changing item values Marc Conrad/Dayou Li 46
CASE STUDY (Cont’d) “Entire” use case model:
April 30, 2020 Marc Conrad/Dayou Li 47
DOCUMENTATION
• Events/activities of each use case must be documented. These are • Insert an item activities that need to • Register • Classify • Calculate value be Returning item customer • Request Receipt documented • Accumulate • Print out item,s value and sum April 30, 2020 Marc Conrad/Dayou Li 48
ACTIVITY DIAGRAM
• • Activity diagram -- showing the sequence of events triggered by an actor and the relationship among the events contained in an use case Events -- being represented as activity states (of an use case) or activity for short.
April 30, 2020 Marc Conrad/Dayou Li 49
ACTIVITY DIAGRAM (Cont’d)
Syntax
Activity Fork Branch Join Merge April 30, 2020 Marc Conrad/Dayou Li 50
ACTIVITY DIAGRAM (Cont’d)
Semantics
• Activity -- event which is the response to a stimulus from an actor • Branch -- conditional selection, only one outgoing transition can be taken • Merge -- the end of conditional behaviour started by a branch • Fork -- the start of parallel operations • Join -- the end of parallel operations April 30, 2020 Marc Conrad/Dayou Li 51
ACTIVITY DIAGRAM (Cont’d)
Example: Recycling machine -- customers return items
When a customer returns an item to the machine, the following activities should happen in the system: -- Register the item -- Classify (crate | can | bottle) -- Increment item quantity -- Increment item value April 30, 2020 Marc Conrad/Dayou Li 52
register Inc item Inc value April 30, 2020 Marc Conrad/Dayou Li 53
Rational Rose activity diagram register bottle can crate increment crate value icnrement crate item increment can value increment bottle value increment bottle item increment can item
CASE STUDY
Wessex Fox is a small bus company operating a number of different routes. Each route has a unique route number and is divided into a number of stages. The same stage may occur in several different routes. For example, both the route from Southampton to Fawley and the route from Southampton to Lyndhurst include the stage Millbrook - Totton. Fares are allocated on the basis of how many stages a passenger's journey incorporates.
Each route is associated with a number of scheduled departure times for particular days of the week and estimated arrival times. For reasons of safety, no two buses can depart at exactly the same time. Once a week, a particular bus and bus driver are allocated to each departure scheduled for the following week. This information is only kept during that current week. The company uses this April 30, 2020 Marc Conrad/Dayou Li information to produce a bus timetable for the use of the drivers.
55
CASE STUDY (Cont’d)
Step 1: System border Wessex Fox April 30, 2020 Marc Conrad/Dayou Li 56
CASE STUDY (Cont’d)
Step 2: Actors: -- Drivers, -- Time Table Makers, -- Manager. April 30, 2020 Marc Conrad/Dayou Li 57
CASE STUDY (Cont’d)
Step 3: Use case: • Driver: request time tables, drive buses, collect fares; • Time table maker: collect departure times, arrival times and information about the allocation of bus drivers, generate new time tables, delete out of date time tables. • Manager: Allocates buses and drivers.
April 30, 2020 Marc Conrad/Dayou Li 58
CASE STUDY (Cont’d)
Driver Request <
Case Study in Rational Rose
Driver April 30, 2020 Request <
SUMMARY
• Various models • Use case diagram • Activity diagram April 30, 2020 Marc Conrad/Dayou Li 61
COS50-3 OOSD
Object Oriented Analysis (Week 3)
April 30, 2020 Marc Conrad/Dayou Li 62
OBJECT
• An
object
is an entity which consists of a number of operations and a state which remembers the effect of the operations. • State is regarded as information which is saved in a set of variables. • Operations read and/or affect the information. • The only part that can be seen by an outsider is the operations. For this reason, operations are also known as
behaviours
. • Information is
hidden
to the outsider. April 30, 2020 Marc Conrad/Dayou Li 63
OBJECT (Cont’d)
Example: a person as an object Information:
Name, Age, Address, Friends, ...
Behaviour:
jump bend legs stretch legs lift arms, ...
walk talk April 30, 2020 Marc Conrad/Dayou Li 64
CLASS and INSTANCE
•
Class
is a template or abstract description of the same type of objects. It defines the common features of the objects, that is the operations and information structure. •
Instance
is an object created from a class. • An instance’s behaviour and information structure is defined in the class. • Its current state (values of instance variables) is determined by operations performed on it. April 30, 2020 Marc Conrad/Dayou Li 65
INHERITANCE
• Inheritance takes place when a subclass of a superclass is created. • A subclass inherits behaviours and information structure (class members) from its parent class. • It can refine the operations and can even add some extra operations and information.
• Note: not all operations and information a subclass can inherit. Pay attention to the the specifiers of class members of a superclass. • Access
private
members is not easy. April 30, 2020 Marc Conrad/Dayou Li 66
POLYMORPHISM
• Very original meaning -- Microorganism propagates itself and no two individuals are exactly the same. So we obtain a variety of individuals. • Original meaning -- the sender of a stimulus doesn’t need to know the receiver’s class.
• Extension -- different receivers can interpret the message in their own way.
• Consequence -- different receivers can response to the same stimulus based on their interpretation. So we can have a variety of objects who process the same piece of data in different ways. • Method overloading and overwriting. April 30, 2020 Marc Conrad/Dayou Li 67
ENCAPSULATION
• Encapsulation is the process of hiding the implementation details of an object. • The only access to manipulate the object data is through its interface. • It protects an object’s internal state from being corrupted by other objects. • Also, other objects are protected from changes in the object implementation. • Encapsulation allows objects to be viewed as ‘black boxes’. • Communication is achieved through an ‘interface’.
April 30, 2020 Marc Conrad/Dayou Li 68
ANALYSIS
• In software engineering, analysis is the process of converting the user requirements to system specification (system means the software to be developed). • System specification, also known as the logic structure, is the developer’s view of the system. • Function-oriented analysis -- concentrating to the
decomposition
a complex function to simply ones. • Object-oriented analysis --
identifying objects
and the relationship between objects. (An object oriented model of a system consists of a number of objects which are the parts of the system.) April 30, 2020 Marc Conrad/Dayou Li 69
OO ANALYSIS
• OO analysis contains the following activities: -- identifying objects: objects must be essential, i.e. always exist, so the system is stable, -- organising the objects: classifying the objects identified, so similar objects can later be defined in the same class, -- identifying relationships between objects: this helps to determine inputs and outputs of an object, -- defining operations of the objects: the way of processing data within an object, -- defining objects internally: information held be the objects. April 30, 2020 Marc Conrad/Dayou Li 70
OO ANALYSIS MODEL
• A model is required to represent the system specification. • The model must be robust and stable. To achieve these, the model must be
implementation environment independent
, so that any change in the implementation environment will not affect the logic structure of the system.
• The model must be able to capture information , behaviour (operations) and presentation (inputs and outputs).
April 30, 2020 Marc Conrad/Dayou Li 71
OO ANALYSIS MODEL
• The model is defined in information -- behaviour - presentation space. behaviour April 30, 2020 information presentation Marc Conrad/Dayou Li 72
OO ANALYSIS MODEL (Cont’d)
Syntax
• Within an use case, we employ three types of objects (in Rational Rose, they are known as three types of entities or stereotypes): Entity On information -- behaviour plane and incline to information axis April 30, 2020 Boundary / Interface Control On the presentation axis On information -- behaviour plane but incline towards behaviour axis Marc Conrad/Dayou Li 73
OO ANALYSIS MODEL (Cont’d)
Semantics
• An entity object models information that shows the state of a system. This information is often used to record the effects of operations and therefore is related to the behaviours of the system. • A boundary/interface object models inputs and outputs and operations that process them. • A Control object models functionality/operations regarding to validate and decide whether to process and pass information from interface object to entity object, or the way around. April 30, 2020 Marc Conrad/Dayou Li 74
OO ANALYSIS MODEL (Cont’d)
Pragmatics
• Identifying interface objects -- functions directly related to actors. • Identifying entity objects -- information used in an use case and functions of processing the information. • Identifying control object -- functions that link interface objects and entity objects April 30, 2020 Marc Conrad/Dayou Li 75
OO ANALYSIS MODEL (Cont’d)
Example: Recycling machine
• Three tasks are often tangled together • We normally start from the refinement of the use case diagram. • Then we identify objects.
• At the “same time”, we organise and identify relationships. April 30, 2020 Marc Conrad/Dayou Li 76
OO ANALYSIS MODEL (Cont’d)
• Refinement of the use case diagram -- Refine use cases by considering include, extend and generalisation. Print April 30, 2020 Return item Generating daily report Marc Conrad/Dayou Li 77
OO ANALYSIS MODEL (Cont’d)
-- Refine actors by considering superclass/subclass and inheritance.
Receipt receiver April 30, 2020 Customer Marc Conrad/Dayou Li Operator 78
OO ANALYSIS MODEL (Cont’d)
-- Refinement also includes adding use cases which are “forgotten” at the previous stage. Print Gene D Report Customer Return item Change item Handle alarm Operator April 30, 2020 Marc Conrad/Dayou Li R Receiver 79
OO ANALYSIS MODEL (Cont’d)
• Identify boundary/interface objects R Receiver Customer April 30, 2020 Receipt printer Operator panel Customer panel Alarm Marc Conrad/Dayou Li Operator 80
OO ANALYSIS MODEL (Cont’d)
• Identify relationship (also know as association) between the identified objects.
Customer panel Receipt printer Operator panel April 30, 2020 Marc Conrad/Dayou Li Alarm 81
OO ANALYSIS MODEL (Cont’d)
When a customer returns a deposit item, it is measured by the system. The measurements are used to determine what kind of can, bottle or crate has been returned. If acceptable,
the total number of items of this type returned by the customer
increments. If not, the light for “Not Valid” is highlighted on customer panel.
When the customer presses the receipt button, the printer prints the date.
The total number of items he returned
and
the lump sum
is calculated. The following is printed out: customer number, number returned, deposit value, total of this type and lump sum April 30, 2020 Marc Conrad/Dayou Li 82
OO ANALYSIS MODEL (Cont’d)
• Identify entity objects. (Let us focus on return item use case.) -- long term information (for all customer): deposit values of bottle, can and crate, -- short term information (for a customer): the total number of items of each type returned by the customer, the total number of items he returned and the lump sum should be paid to him. April 30, 2020 Marc Conrad/Dayou Li 83
OO ANALYSIS MODEL (Cont’d)
Generalisation Deposit items Receipt basis Storing short term info Can Bottle Crate Marc Conrad/Dayou Li Storing long term info 84 April 30, 2020
OO ANALYSIS MODEL (Cont’d)
When a customer returns a deposit item, it is measured by the system. The measurements are used to determine what kind of can, bottle or crate has been returned. If acceptable,
the total number of items of this type returned by the customer
increments. If not, the light for “Not Valid” is highlighted on customer panel.
When the customer presses the receipt button, the printer prints the date.
The total number of items he returned
and
the lump sum
is calculated. The following is printed out: customer number, number returned, deposit value, total of this type and lump sum April 30, 2020 Marc Conrad/Dayou Li 85
OO ANALYSIS MODEL (Cont’d)
• Identify control objects. (We still focus on return item use case.) -- There are entity and boundary objects in this use case. -- Items coming from customer panel need to be measured and decision on whether passing the information needs to be made according the measurement.
-- decision on whether print out information also needs to be made. April 30, 2020 Marc Conrad/Dayou Li 86
OO ANALYSIS MODEL (Cont’d)
deposit item receiver Receipt printer Customer panel receipt basis deposit items Marc Conrad/Dayou Li April 30, 2020 87
OO ANALYSIS MODEL (Cont’d)
Customer panel Deposit item receiver Receipt printer Receipt basis Deposit items can Marc Conrad/Dayou Li bottle crate 88 April 30, 2020