Chapter 7,8,appendix C Object-Oriented Analysis and Design 20.1.

Chapter 7,8,appendix CObject-Oriented Analysis and

Design

20.120.1

Object-Oriented Analysis and Design

Objectives :

Introduction to Object Oriented Approach

Unified Modeling Language

Object Oriented Approach and Technology

Modern Software Development (MSD) process uses object oriented technology and approach.

Most suited to the current business environment. Why ?

As change is continuous it can maintain the system effectively.

It has ability to thoroughly represent complex relationship

Function Oriented approach concentrates how the system functions,


• Whereas Object oriented approach concentrates on its data and the behaviour of the data function.

• Software is build up of self contained objects that work together.

• Each object has data and functions that describe the object and its behaviour respectively.

• Objects interact with other objects to achieve a goal of a software application.


• Object can be • physical like car and employee• Symbolic like graph, shape• Conceptual like accounting system• Event like registration etc.

• When an object is defined, it is responsible for maintaining its data, features and operation on that data.


• Example : Car as an object Car can be described by its colour, chassis, year,

model, price and chassis number Car performs operation such as move, stop, turn

left, turn right, reverse etc.

Advantages:

• OO systems are easy to adapt changes.

• OO approach save development – objects can be reused.


The Object Oriented Approach uses a Unified Approach for software development, which combines the best practices , processes methodologies and guidances given by Booch, Rambaugh and Jacobson to provide better understanding of OO concepts and system development.

It uses Unified Modeling Language (UML) to describe modeling and documentation of a system.


Unified Approach recommends the following process towards system development

Analysis Identification of use cases, objects, classes. Build object oriented analysis model using use case, class

diagrams.

Design Build object oriented design model using analysis model.

Implementation Prototyping and developing the model in increments Continuous testing

The processes are repeated for all the functions till the system is fully developed.

The Unified Modeling Language (UML)

UML provides standard notations for different OO models for better understanding

UML is a modeling language used to create an abstract system scenario by visualizing, specifying, constructing and documenting various components of the system into a representative models.


A wide variety of techniques are used in object oriented analysis and design. These techniques and associated notation are incorporated into a standard object oriented language called the UML.

20.10

20.10


Every UML diagram plays a unique contributory role in improving the understanding of the system.The eight diagrams of UML areStructural modeling

Use Case diagram Static class diagram

Behavioural Modeling Sequence diagram Collaboration diagram State Chart diagram Activity diagram

Implementation Modeling Component diagram Deployment diagram

Structural(Class) Modeling

Structural modeling is described things in a system and how these things are related to each other. A thing can be an object, class, a sub-system or a system.

Structural modeling is very important process because it is employed throughout the entire system development cycle.

Object

An object is a self contained entity that has well defined role in the application domain and has state and behavior.

An object is a tangible or visible entity e.g. person, place or a thing

• Object can be • physical like car and employee• Symbolic like graph, shape• Conceptual like accounting system• Event like registration etc.

ObjectThe state of an object is represented by the values of the properties (attributes) of an object. A object generally has many states, but it can only be in one state at a time. In different states, an object may exhibit different behaviour.

The behaviour of an object represents how an object acts and reacts. An object’s behaviour are also known as functions or methods. The behaviour is determined by a set of operations that the object can perform.

Example of a studentMary represents an object. The state of this object is characterized by its attributes say name, date of birth, year, address and phone and the values these attributes currently have (Mary, 01/01/1990, Texas). Its behaviour is expressed through an operation such as find_dob which is used to calculate a student’s date of birth. Therefore Mary object packages both its state and its behaviour together

ClassesThe term “class ” refers to a group of objects that share a common attributes and common behaviour (operations).

Objects are instances of a class.

A class is like a mold and an instance of a class is like a molded object.

Example

Mary is an object instance, while Student is an object class.

Class diagram

A class is depicted graphically in a class diagram.

In UML, a class is represented by a rectangle with three compartments separated by horizontal lines. The class name appears in the top compartment, the list of attributes in the middle compartments and the list of operations in the bottom compartment of a box.

Shape

-origin-color

+move()+resize()

BankAccount

-account Name-customerName

+getbalance(): float+setbalance()

Examples

Object diagramAn object can be shown in an object diagram as a rectangle with two compartments.

The name of the object and its class are underlined and shown in the top compartment as objectname : classname.

The object’s attributes and their values are shown in the second compartment

Classes

A class has methods and attributes while object instances have behaviour and states

Example: Bank account is a class which covers many different account types. John’s and Mary accounts are instances of the bank account class.

Bank Account-name-balance+debit(in amount)+credit(in amount)

Object1 : Bank Account

Name = John SmithBalance = 1,000.00

Object2 : Bank Account

Name = Robert JonesBalance = - 1,000.00

Classes

The two instances are in different states. John’s account is in the credit state (positive balance), while Robert’s account is in the withdrawn state (negative balance).

The state of the objects can be changed by calling the credit or debit operations. Robert’s account can be changed to the credit state if a credit operation is invoked with a parameter greater than 200.

Attributes

Things in the real world have properties. An attribute is a property of a class.

Attributes attached to classes and objects describe the class or object.

An attribute is a data item where an object holds its own state information.

Attributes have a name, value and data type e.g. integer, Boolean.

Example :

A class automobile has an attribute colour. The domain of values for colour is (white, black, silver, gray, blue, red, yellow, green).

A book can be described in terms of its author, ISBN, publisher, etc.

OperationsEach object can perform a set of functions in order to provide a number of services in a software system.

A service is defined by one or more operations.

An operation is a function or a procedure which can access the object’s data.

An operation consists of two parts name argument(s)

Thus each object must define its operation for each of its services. The collection of operations is the object’s interface. Other objects only need to know the interface of an object in order to invoke the operations provided by the object.

Operations

An operation is sometimes called a method or a member function.

Examples withdraw(amount) deposit (amount) getbalance()

Encapsulation : Information Hiding

It is only through such operations that other objects can access or manipulate the information stored in an object. The collection of operations provides an external interface to a class. The interface presents the outside view of the class without showing its internal structure or how the operations are implemented.It is only the producer, developer of that object that knows the details of the internal construction of that object. The users of an object are denied knowledge of the inner working of the object. Other objects only need to know the interface of an object in order to invoke the operations provided by the object.

Public interface Protected interface

Thus, objects are treated as black boxes. The implementation of objects are hidden from those that use them. This is a powerful concept called “Information Hiding”, better known as encapsulation principle.

Encapsulation : Information Hiding

Example : The operation “GetColor” for the automobile will extract color stored in the color attribute.The class automobile has been designed to receive a stimulus that request the colour of the particular instance of a class. Whenever an object receives a stimulus, it initiates some behavior i.e. retrieve the color of automobile.

Naming Classes

Classes are named as noun or a noun phrase. When using name phrases, eliminate the spaces and concatenate the words with their first letter in uppercase e.g. SavingAccount, BankAccount

Messages

An objects calls another object’s service by sending it a message

Messages are the means by which objects interact.

A message stimulates some behavior to occur in the receiving object. The behavior is accomplished when an operation is executed.

Relationships

Relationships exist among objects which links the type of link that exists between objects. Through the link it is possible to discover the other objects that are related to it. AssociationGeneralizationAggregation

AssociationAn association is a structural relationship that specifies that objects of one thing are connected to objects of another. A plain association is between two peer classes which means that both classes are conceptually at the same level, no one more important than the other.Given an association connecting two classes, one can navigate( send messages) from an object of one class to an object of the other class and vice versa.It is possible that an object of the class can be linked to other objects of the same class.

Association

An association that connects exactly two classes is called a binary association.

An association that connect more than two classes are called n-ary associations.

Graphically, an association is rendered as a solid line connecting the same or different classes.

Use association when you want to show structural relationships.

Association

If an association connects between two objects instead of classes, it is called a link. A link is an instance of an association.

BillGates:Person Microsoft:Company

Name of link

WorkFor

Links provide a convenient way to trace the relationship between objects.

Specify only those relationships that are necessary for the system

Person Company

Name of association

WorkFor

Association

There are four adornments that apply to associations. Name Role Multiplicity Note

Name :

An association can have a name to describe the nature of the relationship. In order to avoid ambiguity about its meaning, the name is given direction by providing a direction triangle that points in the direction the name is to be read as shown below.

Person Company

Name

Name direction

association

Works for

Role

When a class participates in an association, it has a specific role that it plays in that relationship. A role is just a face the class. Each end of an association ha a role e.g. a Person playing the role of employee is associated with a Company playing the role of employer.The same class can play the same or different roles in other associations.

Person CompanyEmployee Employer

Role

Multiplicity :

Multiplicity refers to the number of objects associated with a given object.

In many modeling situations, it is important for you to state how many objects may be connected across an instance of an association. This “how many” is called the multiplicity of an association’s role and is written as an expression that evaluates to a range or an explicit value as shown below.

Multiplicity :

Multiplicity of exactly one is shown as (1), zero or 1 as (0..1), many (0.. *) or one or more a (1 .. *). You can even state an exact number ( e.g. 3).

We can also specify more complex multiplicities by using a list such as 0..1, 3..4, 6..*, which would mean “ any number of objects other than 2 or 5”.


1..n 1

Multiplicity :

If the multiplicity is not specified, the default value of 1 is assumed.

Notes :

A Note is a graphical symbol for holding constraints and comments attached to an objects or a class.

Constraints are restrictions on attributes and associations of an object or a class for which there is no specific notation.

Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment.

Reflexive Association and Roles

A reflexive association is an association that relates one object of a class to another object of the same class. In other words, a class can be associated with itself

Course

Prerequisite For

Association Class

An association can be described by including additional attributes which do not naturally belong to the objects involved in association e.g. the year of enrollment of a student in a course does not belong to the student class or course class. In this case, an association class Enrollment is added to hold the attribute year.

The association class has its own class name, attributes and may have operations also.

Student Course1..n 1Enrolled in

Enrollment

-year

Instructor

Trained by

Taught by


1..n 1WorksFor

Position

-title-starting date-salary

Aggregation :

Aggregation is a stronger form of association. To model a “whole/part or part-of relationship in which one class represents a larger thing ( the “whole”), which consists of smaller things (“ the parts”) is called aggregation. It represents a “has-a” relationship, meaning that an object of the whole has objects of the part. In UML, a link is placed between the whole and parts classes with a diamond head, attached to the whole class to indicate that this is an aggregation.

Company

Department

whole

part

aggregation

1

*

Aggregation :

Aggregation :

Multiplicity can be specified at the end of the association for each of the part-of classes to indicate the quantity of the constituent parts.

Aggregations are not named

Keywords used to identify aggregations are “consists of”, contains, is part of.

A stronger form of aggregation is called composition, which implies whole class has exclusive ownership of the parts classes. This means parts may be created after a composite (whole) is created, but such parts will be explicitly removed before the destruction of the composite.

In UML, a filled diamond indicates the composition relationship.

Composition


1..n 1

Example

WorkFor

Position

-title-starting date-salary

Division

Department

1..n

1..n

Object aggregation

Videotape

Tape ids.

Lecturenotes

Text

OHP slides

Slides

Assignment

Credits

Solutions

TextDiagrams

Exercises

#Problems Description

Course titleNumberYearInstructor

Study pack

School

InstructorCourse

Department

Student

has

Member

attends

Assigned to

teaches

0…1

1*..

*

* * *1* ..

1

1* ..1 1*..

Classes

All objects that exists within a class inherit its attributes and the operations that are available to manipulate the attributes.

A super class is a collection of classes

A subclass is a specialized instance of a class.

Inheritance

The attributes and operations common to a group of subclasses are attached to a super-class and inherited by its sub-classes .

Each subclass may also include new features on its own.

Properties of inheritance

Generalization The purpose of this property is to distribute the

commonalities from the superclass among a group of similar sub classes. The subclass ( derived class) inherits all the superclass’s ( base class) operation and attributes.

Example:

Bank Account

-account number-password-balance +getBalance() : float+setBalance()

CheckingAccount

+checkClearing()

SavingsAccount

-interest+addinterestToBalance()

Generalization

BankAccount (superclass) has an attribute account_number and an operation getBalance(), the CheckingAccount (subclass) will also have the same attribute, account_number and the operation getBalance() as it is a subclass of BankAccount.

It is unnecessary and inappropriate to show the superclass attributes and operations in the subclasses

Specialization

Specialization allows subclasses to extend the functionalities of superclass. A subclass can introduce new operations and attributes of its own.ExampleSavingsAccount inherits attributes account_number, password and balance from BankAccount and extends the functionalities of BankAccount with an additional attribute, interest and an additional operation, addInterestToBalance. A SavingsAccount has the attribute interest that BankAccount does not because not all bank accounts earn interest.

Example - specialization

A subclass Y inherits all of the attributes and operations associate with its super-class X. This means that all data structures and algorithms originally designed and implemented for X are immediately available for Y- no further work need be done. Reuse has been accomplished directly.Any change to the data or operations contained within a super-class is immediately inherited by all subclasses that have inherited from the super-class. Therefore a change in the super class is immediately propagated through a system.

Inheritance

Also, at each level of the class hierarchy, new attributes and operations may be added to those classes that have been inherited from higher levels in the hierarchy.

X1

CHAR1 CHAR2

CHAR3

X1

X2

CHAR1 CHAR2 CHAR3 CHAR4

CHAR5

X3

CHAR1 CHAR2 CHAR3 CHAR4 CHAR5

CHAR6

X4

CHAR1 CHAR2 CHAR3 CHAR4 CHAR5 CHAR7

CHAR 4 + CHAR 5

CHAR 7CHAR 6

Library class hierarchy

Catalogue numberAcquisition dateCostTypeStatusNumber of copies

Library item

Acquire ()Catalogue ()Dispose ()Issue ()Return ()

AuthorEditionPublication dateISBN

Book

YearIssue

MagazineDirectorDate of releaseDistributor

Film

VersionPlatform

Computerprogram

TitlePublisher

Published item

TitleMedium

Recorded item

User class hierarchyNameAddressPhoneRegistration #

Library user

Register ()De-register ()

Affiliation

Reader

Items on loanMax. loans

Borrower

DepartmentDepartment phone

Staff

Major subjectHome address

Student

Multiple inheritanceRather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classesCan lead to semantic conflicts where attributes/services with the same name in different super-classes have different semanticsMakes class hierarchy reorganisation more complex

Multiple inheritance

# Tapes

Talking book

AuthorEditionPublication dateISBN

Book

SpeakerDurationRecording date

Voice recording

How to perform object oriented analysis

A software engineer should perform the following generic steps Elicit customer requirements for the system Identify scenarios or use case Select classes and objects using basic

requirements as a guide Identify attributes and operations that

organize classes Build an object relationship model Review the OO analysis model against use

cases or scenarios.

Use-Case DiagramsApplied to analyze functional requirements of the systemPerformed during the analysis phase to help developers understand functional requirements of the system without regard for implementation detailsUse-Case modeling is done in the early stages of system development life cycle, which helps developers to gain a clear understanding of the functional requirements of the system, without worrying about how to implement the requirements.

20.74

20.74

What is a Use case Model?

A use case model/diagram captures all the functions (known as use cases) carried out in the system.

A use case contains a set of scenarios and each scenario should describe all possible sequence of interactions between a system and a user in a particular environment that are related to a particular role.

What is a Use case?

A use case describes the behaviour of a system under various conditions as the system responds to request from principal actors. In other words, each scenario includes a normal interaction (main flow) plus scenarios for each possible exception.A use case can be stated as a present –tense verb phrase, containing the verb and the object of the verb e.g. compute gpa of student

Elements of a Use Case Diagram

Actors: An actor is an external entity that interacts with the system. An actor portrays any entity (or entities) that exchange information with the system. An actor in a use case diagram interacts with a use case to accomplish a specific goal. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor.

Elements of a Use Case DiagramThere is a difference between an actor and a user.A user is anyone who uses the system.An actor on the other hand, represents a role that a user can play. The actor’s name should indicate that role.An actor is a type or class of users; a user is a specific instance of an actor class playing the actor’s role.A same user can play multiple role.As actors are outside the system, there is nor need to describe them in detail.The advantage of identifying actors is that it helps us to identify the use cases they carry out.

An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure 1.

Figure 1: an actor in a use case diagram


To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the roles played and can be easily identified as actors in the system.


Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. In other words, each use case must perform a distinct function.As the first step in identifying use cases, you should list the discrete business functions in your problem statement. Each of these business functions can be classified as a potential use case.

Figure 2: use cases in a use case diagram

The name of the use case can be listed inside the ellipse or just below it.


Figure 2 shows two uses cases: "Make appointment" and "Perform medical tests" in the use case diagram of a clinic system. As another example, consider that a process such as "manage patient records" can in turn have sub-processes like "manage patient's personal information" and "manage patient's medical information."


System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system.

Figure 3: a use case diagram depicting the system boundary of a clinic application


Figure 3 shows the system boundary of the clinic application. The use cases of this system are enclosed in a rectangle. Note that the actors in the system are outside the system boundary. The actors are connected to use cases with lines and that use cases are connected to each other with arrows

The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case.

Elements of a Use Case DiagramFor large and complex systems, each of the modules may be the system boundary. For example, for an Enterprise system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. The entire system can span all of these modules depicting the overall system boundary.

Relationships in Use Cases

Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. Use case relationships can be one of the following:

Relationships in Use CasesInclude: When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship. Literally speaking, in an include relationship, a use case includes the functionality described in the another use case as a part of its business process flow. An include relationship is depicted with a directed arrow having a dotted shaft. The tip of the arrowhead points to the child use case and the parent use case is connected at the base of the arrow. The stereotype "<<include>>" identifies the relationship as an include relationship.


The dotted line arrow does not indicate any kind of data or process flow between use cases.The use case that is “included” represents a generic function that is common to many business functions. Rather than reproduce that functionality with every use case that needs it, the functionality is factored out in a separate use case that can be used by other use cases.

Figure 4: an example of an include relationship


For example, in Figure 4, you can see that the functionality defined by the "Validate patient records" use case is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" use case executes, the steps defined in the "Validate patient records" use case are also executed.


Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<<extend>>" identifies the relationship as an extend relationship, as shown in Figure 5.

Figure 5: an example of an extend relationship


Figure 5 shows an example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use case.


Generalizations: A generalization relationship is also a parent-child relationship between use cases. The child use case in the generalization relationship is an enhancement of the parent use case. In a use case diagram, generalization is shown as a directed arrow with a triangle arrowhead (see Figure 6). The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case.

Figure.6: an example of a generalization relationship

back


On the face of it, both generalizations and extends appear to be more or less similar. But there is a subtle difference between a generalization relationship and an extend relationship.

Relationships in Use CasesWhen you establish a generalization relationship between use cases, this implies that the parent use case can be replaced by the child use case. On the other hand, an extend relationship between use cases implies that the child use case enhances the functionality of the parent use case into a specialized functionality. The parent use case in an extend relationship cannot be replaced by the child use case.

Relationships in Use CasesFrom the diagram of a generalization relationship (refer to Figure 6), you can see that "Store patient records (paper file)" (parent) use case is depicted as a generalized version of the "Store patient records (computerized file)" (child) use case. Defining a generalization relationship between the two implies that you can replace any occurrence of the "Store patient records (paper file)" use case in the system with the "Store patient records (computerized file)" use case without impacting any function. This would mean that in future you might choose to store patient records in a computerized file instead of as paper documents without impacting other functions in the system.

Relationships in Use CasesNow, if we had defined this as an extend relationship between the two use cases, this would imply that the "Store patient records (computerized file)" use case is a specialized version of the "Store patient records (paper file)" use case. Hence, you would not be able to seamlessly( without effort) replace the occurrence of the "Store patient records (paper file)" use case with the "Store patient records (computerized file)" use case.

ATM ExampleAn ATM system will have a key operated switch that will allow an operator to start and stop the servicing of customers. The ATM will serve on customer at a time. A customer will be required to insert an ATM card and enter a PIN both of which will be sent to the bank for validation as part of each transaction. If the PIN is not valid, then perform the use-case “invalid PIN”.Whenever a customer inserts an ATM card in the card reader of an ATM, a transaction can be started. The customer will then be able to perform one of the following transactions

A customer must be able to make a cash withdrawal. A customer must be able to make deposits to any account A customer must be able to make transfer of money between any two

accounts linked to the card. A customer must be able to make a balance inquiry of any account linked to

the card.

Example:Draw a use case diagram (specify the relationship if any) for a university registration system. Class registration , which is the basic flow (course number, section number, term, year) is carried out by the registration clerk. He checks whether the student has opted for registration of special classes (alternative flow). If yes, the Registration for special classes use case will be performed. Registering for a special class requires prior permission of the instructor in addition to the other steps carried out for a regular registration. In normal cases, only class registration would be performed, because students would have met the prerequisite requirements. However, in situations where a student has not taken one or more of the prerequisite, the Prereq course not completed use case is performed. Student billing is initiated by University office, which interacts with the student instances by mailing the tuition invoices.

Figure 20-2Use-case diagram for a university registration system

20.10520.105

Sequence diagrams

Sequence diagrams is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order and the inter-system events.

All systems are treated as a black box

The emphasis of this diagram is events that cross the system boundary from actors to systems.

The sequence diagram is a very useful tool to easily represent the dynamic behaviour of a system.

The sequence diagrams purpose

The sequence diagram is used to primarily to show the interactions between objects in the sequential order that those interactions occur.An organization’s technical staff can find sequence diagrams useful in documenting how a future system should behave.An organization’s developers can use this diagram to force out the system’s object interactions thus fleshing out overall system design.

Elements of Sequence Diagram

Object:

This is the primary element involved in a sequence diagram is an object ( actor or an instance of a class). A sequence diagram consist of sequences of interaction among different objects over a period of time. An object is represented by a named rectangle with a dashed line descending from the center of the bottom edge. . The name to the left of the “:” is the object name and to its right is the class name.

freshman: student

Fig No.1


Messages: The interaction between objects in a sequence diagram is represented as messages.An object sends a message to another object, by means of a line with an arrow pointing towards the receiving object. The message/method name is placed above the arrowed line. The message that is being sent to the receiving object represents an operation/method that the receiving object’s class implements.


The first message of a sequence diagram starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.


Return Message. A return message is drawn as a dotted line with an arrowhead back to the originating lifeline and above this dotted line return value from the operation is placed. The return messages are optional part of a sequence diagram. Return messages are useful if finer details is required, otherwise invocation message is sufficient.


Iterations:

A box is drawn to show the iterations i.e. the message are repeated a number of times.

Withdraw request

Verify account

Account OK

Withdraw request OK

Verify card details

Card details OK

Scenario for processing a Sale using POS system.

1. Customer arrives at a POS checkout with goods and /or services to purchase.

2. Cashier starts a new sale.3. Cashier enters item identifier, and quantity.4. System records sale line item and presents item description,

price and running total.5. Cashier repeats steps 3-4 until indicates done( end sale)6. System presents total with taxes calculated7. Cashier tells Customer the total and asks for payment8. Customer pays ( make payment) 9. System handles payment i.e. outputs how much change is

due and receipt.

Requirement Statement for using an Elevator

A product is to be installed to control elevators in a building with m floors. The problem concerns the logic required to move elevators between floors according to the following constraints: Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the elevator visits the corresponding floor. Each floor, except the first floor and top floor has two buttons, one to request and up-elevator and one to request a down-elevator. These buttons illuminate when pressed. The illumination is canceled when an elevator visits the floor and then moves in the desired direction. When an elevator has no requests, it remains at its current floor with its doors closed.

Basic scenario of an Elevator

Passenger pressed floor button Elevator controller detects floor button pressed Elevator Controller moves Elevator to the floor Elevator Controller makes the Elevator doors open Passenger gets in and presses elevator button Elevator Controller makes the Elevator doors close Elevator Controller makes the Elevator moves to required floor Elevator Controller makes the Elevator doors open Passenger gets out Elevator Controller makes the Elevator doors close

Object behaviour modelling

A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case

Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects

Issue of electronic items

:Library User

Ecat:Catalog

Lookup

Issue

Display

:Library Item Lib1:NetServer

Issue licence

Accept licence

Compress

Deliver

Chapter 7,8,appendix C Object-Oriented Analysis and Design 20.1.

Documents

Transcript of Chapter 7,8,appendix C Object-Oriented Analysis and Design 20.1.