Software development process: Problem decomposition and analysis

Where do I start?

• Last time we discussed five main activities of software development:– analysis– design– implementation– testing– maintenance

Analysis

• “What are we trying to do?” (not how)

• Functionality described in some standardized way (e.g. use cases, user stories) .

• Functionality must be testable or verifiable.

Analysis

• You have to clearly define the problem. This is usually a negotiation between the customer and the developers. They tell you what they want, you get clarification, and see if what they want is really what they say they want.

• Remember, customers aren’t developers – they are problem domain experts.

• Remember, developers don’t know the problem domain, and should not make unwarranted assumptions about it.

• It is a part of a developer’s job to get answers to technical questions from the customer by asking non-technical questions of the customer (i.e. by asking questions in terms that the customer understands).

Design

• “What structure does my system need to support the (customer’s) required functionality?”

• Identify classes, responsibilities, and relationships…but how? What is a good process of design discovery?

• This is an iterative process. You won't get it right the first time, and thinking that you did will only cause you problems later on.

• What are end products of design? These could be class diagrams, state diagrams, textual description of classes, etc.

Implementation

• “How do I build the system from my design?”

• How can work be divided amongst many developers?

• How are the efforts of many developers coordinated?

• How is the code of many developers integrated?

Implementation

• Build it. This usually leads to changes in phase 1 (analysis) and 2 (design).

• It is misleading to think of these as discrete and sequential phases.

• Each phase will lead to a return to the other parts, as problems require re-negotiation, clarification, restructuring, etc.

• The extreme programming (XP) methodology advocates an interleaved and iterative process of analysis, design, implementation and testing.

Testing

• “How do I know whether my implementation is faithful to the requirements?”

• Test Driven Development– Develop tests after specification, before

implementation.– Tests capture the essence of requirements: they are an

executable expression of requirements.

• There are many different types of tests that can be performed. We will focus on what are called unit tests.

Example

• The big boss says : "We want to build a web site that will allow our customers to order merchandise, will store user profiles, verify payment information, and put together an invoice".

Clarifications

• How do they order?• Does it store order history?• How are products/prices updated?• What types of payments can they make?• What happens once the invoice is generated?• What information gets stored in a user profile?• What administrative aspects need to be included?• What security will be involved?

Analysis of Example

• The “project statement” is not very well defined, or very conducive to creating a design document. This is unfortunately almost always the case when you are presented with a project, especially from non-technical users. What things need to be clarified in the request?

Revised Statement

• "We want to build a web site that will allow our customers to create a user account, and then sign on to our web site. The user account will have their name, address, and email. Once there, they can pick items from our catalog, which will then be placed in a shopping cart. When they check out, it will collect and verify payment information, generate an invoice, and store the order in a history table. It will then send that invoice to the warehouse for processing, and send a confirmation email to the user. All pages on the site will be encrypted.”

Discovering Classes

• When designing classes , look for the nouns in the project description.

Revised Statement - Nouns

• "We want to build a web site that will allow our customers to create a user account, and then sign on to our web site. The user account will have their name, address, and email. Once there, they can pick items from our catalog, which will then be placed in a shopping cart. When they check out, it will collect and verify payment information, generate an invoice, and store the order in a history table. It will then send that invoice to the warehouse for processing, and send a confirmation email to the user.

This is a balancing act!

• If you make things too specific, then you will be mislead.

• In our example - no need for classes for products, one product class suffices.

• Too general is also bad; if you just have a “Web Ordering” class, and it does everything, then it isn't really object oriented; it is a functional program jammed into one big object.

Other strategies for discovering classes

• Agents - This is turning a method into a class that specializes in this. For example, renderers, tokenizers,processors, translators, etc."Payment Verifier", "Invoice Generator", "Order Processor"

• Events and transactions - very important in data oriented applications; adds, updates, deletes, or at low level mouse moved, keyboard input, exception. Transaction interface for logging?

Strategies, Continued

• Users and roles - any app with users (and this is most) needs to identify user info, such as permissions, or address info, or security data, or preferences. "Customer", "Admin"

• Systems - this is the overall controller, or controllers, of the project. Server, client, interface. OrderProcessor?

Strategies, Continued

• System interface - File io, database, mail, messaging, sockets, etc. ConfirmationMailer, OrderHistoryWriter

• Foundational classes - assume that these exist. String, Date, Rectangle, Shape.

Finding Responsibilities

• When looking for responsibilities to assign to the classes, look for verbs in the project description.

Revised Statement - Verbs

• We want to build a web site that will allow our customers to create a user account, and then sign on to our web site. The user account will have their name, address, and email. Once there, they can pick items from our catalog, which will then be placed in a shopping cart. When they check out, it will collect and verify payment information, generate an invoice, and store the order in a history table. It will then send that invoice to the warehouse for processing, and send a confirmation email to the user.

Strategies For Discovering Responsibilities

• Responsabilities should belong to one class, and only one class. They can be augmented (decorator, facade, etc), but the core responsability should belong to one place, and not half in one, half in another. This does not mean that subclasses can't handle components of the responsability, but there shouldn't be two top level classes. You wouldn't make a roundshapes renderer, and a squareshapes renderer, and make the client call both.

Strategies, Continued

• Pay attention to "layering of abstraction levels". A class should probably not be handling high and low level responsibilities. For example, the Order class should not be reading orders from the web form and also writing a record of the order to the disk.

CRC Cards

• A very flexible design technique

• Use index cards, and list responsibilities on the left, and associated classes on the right.

• Move, split, erase, etc as the system design progresses.

General Design Hints• Avoid "mission creep". If a class does too much,

split it.• Avoid having unrelated things in a class. This

also goes back to the levels of abstraction.• DONT DO THINGS JUST BECAUSE YOU

CAN! Sorting if not necessary, translation to French, etc.

• Avoid a bunch of small, unused classes too. Balancing act.

• If you have a bunch of attributes, consider rolling them up into classes as well.