Once these have been identified, further brainstorming can take place to

Principles to Guide a Brainstorming Session by
Bellin and Simone First, all suggestions should betaken seriously. At this point in the development of the system, it is much better to have to delete something later than to accidentally leave something critical out. Second, all participants should begin thinking fast and furiously. After all ideas are out on the proverbial table, then the participants can be encouraged to ponder the candidate classes they have identified.

Principles to Guide a Brainstorming Session by
Bellin and Simone Third, the facilitator must manage the fast and furious thinking process. Otherwise, the process will be chaotic. Furthermore, the facilitator should ensure that all participants are involved and that a few participants do not dominate the process. To get the most complete view of the problem, we suggest using a round-robin approach wherein participants take turns suggesting candidate classes. Another approach is to use an electronic brainstorming tool that supports anonymity. Fourth, the facilitator can use humor to break the ice so that all participants can feel comfortable in making suggestions Seems having similarity with JAD?

A common object list is simply a list of objects common to the business domain of the system. Several categories of objects have been found to help the analyst in creating the list, such as physical or tangible things, incidents, roles, and interactions. Analysts should first look for physical, or tangible, things in the business domain. These could include books, desks, chairs, and office equipment. Normally, these types of objects are the easiest to identify.
–
Incidents are events that occur in the business domain, such as meetings, flights, performances, or accidents. Common Object Lists

Reviewing the use cases can readily identify the roles that the people play in the problem, such as doctor, nurse, patient, or receptionist. Typically, an interaction is a transaction that takes place in the business domain, such as a sales transaction. Other types of objects that can be identified including places, containers, organizations, business records, catalogs, and policies Common Object Lists

The idea of using patterns is a relatively new area in object-oriented systems development. There have been many definitions of exactly what a pattern is. From our perspective, a pattern is simply a useful group of collaborating classes that provide a solution to a commonly occurring problem. Because patterns provide a solution to commonly occurring problems, they are reusable. According to Alexander and his colleagues, it is possible to make very sophisticated buildings by stringing together commonly found patterns, rather than creating entirely new concepts and designs. Ina similar manner, it is possible to put together commonly found object- oriented patterns to form
elegant
object-oriented information systems. Patterns

For example, many business transactions involve the same types of objects and interactions. Virtually all transactions would require a transaction class, a transaction line item class, an item class, a location class, and a participant class. By reusing these existing patterns of classes, we can more quickly and more completely define the system than if we start with a blank piece of paper. If we are developing a business information system in one of these business domains, then the patterns developed for that domain maybe a very useful starting point in identifying needed classes and their attributes, operations, and relationships. Patterns

Useful Patterns

Samples of Pattern

Samples of Pattern (Integration)

1 . 2 CLASS RESPONSIBILITY- COLLABORATION CR CC AR D S

In addition to the object identification approaches described earlier textual analysis, brainstorming, common object lists, and patterns,
CRC cards can be used in a role-playing exercise that has been shown to be useful in discovering additional objects, attributes, relationships, and operations. Introduction

•
Responsibilities of a class can be broken into two separate types
knowing
and
doing
.
–
Knowing
responsibilities are those things that an instance of a class must be capable of knowing. An instance of a class typically knows the values of its attributes and its relationships.
–
Doing
responsibilities are those things that an instance of a class must be capable of doing. In this case, an instance of a class can execute its operations or it can request a second instance, which it knows about, to execute one of its operations on behalf of the first instance Responsibilities

The structural model describes the objects necessary to support the business processes modeled by the use cases. Most use cases involve a set of several classes, not just one class. These classes form collaborations. Collaborations allow the analyst to think in terms of clients, servers, and contracts
–
A client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. A server object is the instance that receives the request from the client object. A contract formalizes the interactions between the client and server objects. Collaboration Objects working together to service a request Collaborations

The idea of class responsibilities and client–server–contract collaborations can be used to help identify the classes, along with the attributes, operations, and relationships, involved with a use case.
•
Anthropomorphism—pretending that the classes have human characteristics.
•
Members of the development team can either ask questions of themselves or be asked questions by other members of the team. Typically the questions asked are of the form Who or what are you What do you know What can you do The answers to the questions are then used to add detail to the evolving CRC cards.
CRC (Class-Responsibility- Collaboration)

For example, in the appointment problem, a member of the team can pretend that he or she is an appointment. In this case, the appointment would answer that he or she knows about the doctor and patient who participate in the appointment and they would know the date and time of the appointment. Furthermore, an appointment would have to know how to create itself, delete itself, and to possibly change different aspects of itself. In some cases, this approach will uncover additional objects that have to be added to the evolving structural model. Example of Anthropomorphism

A CRC Card

•
Role-playing is very useful in testing the fidelity of the evolving structural model Technically speaking, the members of the team perform the different steps associated with a specific scenario of a use case.
•
Consists of 4 steps Review Use Cases Identify Relevant Actors and Objects
3.
Role-Play Scenario Repeat Steps 1 to 3
Role-Playing CRC Cards with Use Cases

This allows the team to pick a specific use case to role-play. Even though it is tempting to try to complete as many use cases as possible in a short time, the team should not choose the easiest use cases first. Instead, at this point in the development of the system, the team should choose the use case that is the
most important
, the
most
complex
, or the
least understood

Role-Playing CRC Cards with Use Cases

Each role is associated with either an actor or an object. To choose the relevant objects, the team reviews
each of the CRC cards and picks the
ones that are associated with the
chosen use case. For example, we see that the CRC card that represents the Old Patient
class is associated with Use Case number 2.
Role-Playing CRC Cards with Use Cases -- Second Step – Identify Relevant Actors and Objects

So if we were going to role-play the Make Old

Download 1.31 Mb.

Share with your friends: