Software Engineering 2007/2008 Chapter 6 Considering Objects

2007/2008 Software Engineering

Chapter 6

Considering Objects

Learning objectives

Explain what is meant by object-oriented development, and how it differs from other development paradigms(范例 );

Understand what use cases are, discuss why they can be useful in software development, and use them to describe system functionality

Use and understand UML diagrams Explain how object-orientation is used for system design Explain how object-orientation is used for program desig

n;

6.1 WHAT IS OO? Object orientation is an approach to software development.

both the problem and its solution as a collection of discrete objects; both data structure and behavior are included in the representation.

OO use classification(分类 ) to group objects that have attributes( 属性 ) and behaviors in common.each group can be considered a class

FIGURE 6.1 Example of objects grouped into classes

6.1 WHAT IS OO?

Each object in an OO system usually has name,also called a reference or handle; a set of attributes;and a set of behavior

FIGURE 6.2 Box representing an object’s name,attribute,and behavior

6.1 WHAT IS OO?

Attribute are simple variables whose values can vary over time and among different entities of the class

behavior is an action or transformation that an object performs

Sometimes, the same behavior may be exhibited( 呈现 ) differently on different class or subclass, a property called polymorphism(多态性 )

seven characteristics: Identity( 同一性 ), abstraction( 抽象性 ), classificatio

n ( 分类性 ), encapsulation( 封装性 ), inheritance( 遗传性 ) , polymorphism(多态性 ), and persistence( 持久性 )

6.2 THE OO DEVELOPMENT PROCESS

One advantage of OO development is its consistency ( 一致性 ) of language. We can describe both the problem and the solution in the same terms: classes, objects, methods, attributes and behaviors. No matter where in the process we represent an object, we must include the object's name, attributes, and behaviors. At the next higher level, describing classes using OO representation requires three perspectives: static, dynamic, and restrictive ( 限制性 ).

Static view(观察 ) include descriptions of the objects, attributes, behaviors, and relationships

Dynamic view describe communication, control/timing,and the states and state changes

The restrictions describe constraints( 约束 ) on the structure and the dynamic behavior.

6.2 THE OO DEVELOPMENT PROCESS

OO Development Processes1. OO Requirements No matter what the life cycle, an OO development proce

ss requires steps for describing requirements, designing the system, designing the programs, coding, and testing. OO requirements analysis is usually done in the user’s language and discusses the the concepts and scenarios( 想定 ) likely in the application domain

2. OO Design There are two guidelines that apply to representing a sys

tem design in an object-oriented way. First, we should identify and represent classes and object. Second, we must identity( 同一性 ) the interactions( 交互作用 ) and relationships among objects and class

6.2 THE OO DEVELOPMENT PROCESS3. OO Coding and Testing

Once the program design is done, the system is described at a very low level, using models of objects, attributes, and behaviors.Coding proceeds by translating the models to an OO programming language.

Testing an OO system involves some of the same activities that are performed when testing any kind of system. The coders unit-test their own work, then cooperate with the test team to do integration, system, and acceptance testing.

FIGURE 6.4 Relationship of testing types to OO structure

6.3 USE CASES

To development a system using an object-oriented approach, it is help to elicit requirements and describe them with a technique known as use case

A use case describes particular functionality that a syst

em is supposed to perform or exhibit The entity interacting with the system is called an acto

r,and it can be a user,a device or another system Use case diagrams have four elements: actors, case, ex

tension( 范围 ), and uses

6.3 USE CASES

FIGRUE 6.5 Overview of Royal Service Station

FIGURE 6.6 First extension of Royal Service Station diagram to include preventive maintenance

ROYAL SERVICE STATION REQUEREMENTS

Book Page 197 SIDEBAR 6.1

6.3 USE CASES

FIGURE 6.7 Second extension of Royal Service Station Diagram to include credit card system

6.3 USE CASES Finally, we extend the system to include all participants

(参与者 ). To do that, we look for all entities(实体 ) in the environment that interact(互相影响 ) with the system to accomplish a task or provide a service. We can use a set of questions to help us identify participants: What users or groups use the system to perform a task? What users or groups are needed so that the system can perform i

ts functions? What external systems use the system to perform a task? What external systems, users, or groups send information to the s

ystem? What external systems, users, or groups receive information fro

m the system?

6.3 USE CASES

FIGURE 6.8 Third extension of Royal Service Station diagram to include inventory and accounting

6.3 USE CASES

Once we have use cases,we can examine them further to find existing and potential problems. For example, we can ask the following kinds of questions: Do the use cases use the right terminology? That

is, are there two or more terms to describe the same entity or actor in the requirement?

Do the activities match the perspectives? That is ,does a use case describe system interaction with a participant in a way that is consistent with the description of the participant?

6.3 USE CASES

Are the descriptions of activities and participants clear and complete? Is there more than one way to interpret the description?

Is there an interaction described that is missing its complementary participant description?

Is there an external system or set of users described but not actually involved in an activity or interaction with the system?

Is it clear when each activity starts and ends?

6.4 REPRESENTING OO: AN EXAMPLE USING UML

UML in the process

UML is a notational approach that is popular for describing OO solutions. Figure 6.9 shows how UML can be used in requirements specification, design, and coding.

FIGURE 6.9 How UML supports the development process

6.5 OO SYSTEM DESIGN

The design process starts with a statement of the requirements. We try to extract nouns ( 析取名词 ), looking for particular items that can suggest our first cut at object classes.we seek( 寻找 ): structures external systems devices roles operation procedures places organization thing that are manipulated( 使用 ) by the system to be built


Example: the first Royal Service Station requirement: A customer has the option to be billed automatically at the

time of purchase(of fuel, maintenance or parking ) or to be sent a monthly paper bill. In either case, customers can pay using cash, credit card, or personal check. Royal Service Station fuel is sold according to price per gallon, depending on whether the fuel is diesel, regular, or premium. Service is priced according to the cost of parts and labor. Parking is sold according to daily, weekly, and monthly rates. The prices for fuel, maintenance services, parts, and parking may vary; only Manny, the station manager, can enter or change prices. At his discretion, Manny may designate a discount on purchases for a particular customer; this discount may vary from one customer to another. A 5% local sales tax applies to all purchase

6.5 OO SYSTEM DESIGN From this requirements statement,we can extract

several tentative classes, including Personal check Paper bill Credit card Customer Station manager Purchase Fuel Services Discounts Tax Parking Maintenance Cash prices


These questions can as guidelines for what can be included in a list of candidate classes:

1. What needs to be “processed” in some way? 2. What items have multiple attributes? 3. When do you have more than one object in a class 4. What is based on the requirements themselves, not

derived from you understanding of the requirements? 5.what attributes and operations are always applicable to a

class or object? These questions can help us to group the candidate classes

and objects as show in table 6.2


Attribute Classespersonal check customertax maintenanceprice servicescash parkingcredit card fueldiscounts bill

purchasestation manager

TABALE 6.2 First Grouping of Attributes and Classes:Step


Next we examine other requirements to see what they add to our exiting table of attributes and classes ,for example

The system applies only to regular repeat customers. A regular repeat customer means a customer identified by name, address, and birthdate who uses the station’s services at least once per month for at least six months

The system will send periodic message to customers, reminding them when their vehicles are due for maintenance. Normally, maintenance is needed every six months


Attri bute Cl assespersonal checkcustomertax mai ntenancepri ce servi cescash parki ngcredi t card fueldi scounts bi l lbirthdate purchasename periodic messageaddress stati on manager

TABALE 6.3 First Grouping of Attributes and Classes:Step:2

6.5 OO SYSTEM DESIGN For the full set of requirements, we might expand our table

to include all of the classes in table 6.4 Attri bute Cl assespersonal check customertax mai ntenancepri ce servi cescash parki ngcredi t card fueldi scounts bi l lbirthdate purchasename periodic messageaddress stati on manager

waring letterpartsaccountsinventorycredit card systempart-ordering systemfuel-ordering system

TABALE 6.4 First Grouping of Attributes and Classes:Step:2


Next,we identify behaviors that be described in our design. From the requirements statements, we extract verbs again,we can look for particular items that suggest behaviors imperative verbs Passive verbs Actions Things or reminded events Roles Operation procedures Services provided by an organization


Design classes

FIGURE 6.10 Class box representing a bill


Relationships

FIGURE 6.11 Inheritance relationship


FIGURE 6.12 Association of classes


FIGURE 6.13 Type of class relationships


FIGURE 6.14 Additional UML notation for notes and qualifiers


FIGURE 6.15 First cut at Royal Service Station design


FIGURE 6.15 Second cut at Royal Service Station design


FIGURE 6.15 Third cut at Royal Service Station design


FIGURE 6.18 Package diagram for the Royal Service Station


FIGURE 6.19 Sequence diagram for the refuel use case


FIGURE 6.20 Collaboration diagram for the packing use case


FIGURE 6.21 State diagram example


FIGURE 6.22 State diagram for inventory class


FIGURE 6.23 State diagrams for inventory class


FIGURE 6.24 Activity diagram notation


FIGURE 6.25 Activity diagram for inventory class

6.6 OO PROGRAM DESIGN

Our program design efforts begin with the objects and classes from the system design, but we must embellish and modify them to include more items: nonfunctional requirements, such as performance and

input/output constraints reused components from previously built systems reusable components intended for use in more systems than

just the one at hand user interface requirements data structure and management details


Design Aids( 设计工具 ) No one way of designing is best for all situations. The onl

y guideline that applies to all system is this:design for change. No matter what system you are building, it is likely to change at some time or other. There are many OO-related techniques to help you make the system more flexible and maintainable.

A toolkit: is a set of related, reusable classes that provide a well-defined set of functionality. For example, you may employ a toolkit to build the user interface from buttons and windows, rather than write the code anew yourself.


Frameworks and patterns are also design aids. They differ form a toolkit in that they are more focused on design reuse than on code reuse. For example, suppose you are building an interactive display of stored values. Gamma et al suggest that you use the mode-view-controller pattern. The model is a set of classes that contain the stored information. The view is a set of classes that implement the user interface. The controller classes control the interaction between the user interface and the stored data.


A pattern is a template of abstract architectural elements that can be used guide you in generating you design.Every pattern has a context and forces defined with it. The context explains the situations in which the pattern would be appropriate. The force are elements of the context that vary to some degree.

A framework is a reuse of part of a domain-specific design. It is more specialized than a design pattern, and it can incorporate patterns in its specification.


User Interface Design To complete the user interface portion of a program design,

we must consider several issues: defining the humans who will interact with the system developing scenarios for each way that the system can

perform a task designing a hierarchy of user commands refining the sequence of user interactions with the

system designing relevant classes in the hierarchy to

implement the user interface design decisions integrating the user interface classes in the overall

system class hierarchy


FIGURE 6.26 Transition from paper to screen


FIGURE 6.26 Possible design for new billing screen


Data Management Design

The program design must also address ways to store and recover persistent objects. The data management takes into account the system requirements and constraints, we must lay out a design for the objects and for their operations. We can perform this task in four step: Identify the data, data structures, and relationships

among them. Design services to manage the data structures and

relationships Find tools, such as database management systems, to

implement some of the data management tasks. Design classes and class hierarchies to oversee the data

management functions


FIGURE 6.28 Implementing the class using a relational database


Task Management DesignTask management is a critical part of program design.

We must scrutinize the requirements and determine how to coordinate the activities the system is to perform. A task refers to a process in the system; it may be event-driver or time-driven. An event-driven task is initiated when a particular event occurs, such as when a mouse is moved, a button is pressed, or a sensor sends or receives a message. A time-driven task is invoked at a particular time, such as every n minutes.


We can design the task management in four step: Identify the tasks to be performed, and classify

them as event- driven or time-driven. Determine priorities for the tasks. That is, for

each pair of tasks, decide which one has priority if two are to be invoked simultaneously

Create a task to coordinate all other tasks. Design objects for each task, and define the

relationships among them.


Each task must be defined formally, so that the programmers understand how to implement it properly. To assist the programmers, we should include the task name, description, priority, services, communication mechanism, and place in the hierarchy. For instance, the task to order parts may have a task definition like this:

Task name: order name Description : purpose is to order new parts automatically

when there are not enough parts already in stock Priority: High, It must be activated when the inventory

warms that parts in stock are low Included services: Verify inventory. Managed by/Manages: Service Station system Communicates by: modem with the order_parts system

Documents

Software Engineering 2007/2008 Chapter 6 Considering Objects