Object-Oriented Analysis: Use Cases

• Object-oriented analysis involves identifying use cases, object analysis through classification, and identifying object relationships, attributes, and methods.

Identifying Use Cases

• The use-case approach is used for object-oriented analysis.
• The process involves identifying actors, use cases, and documentation.
• Analysis transforms a fuzzy problem definition into a coherent statement of system requirements.
• It aims to capture a complete, unambiguous, and consistent picture of the system's requirements.
• It focuses on what the system must do to satisfy user needs.
• Start by examining existing system documentation, conducting interviews, using questionnaires, and making observations.
• Common issues involve incomplete requirements, fuzzy descriptions, and unneeded features.
• The OOA process includes identifying actors, developing a simple business process model using UML activity diagrams, and developing use cases to document the system.
• Further steps involve preparing interaction diagrams, classification (identifying classes, relationships, attributes, and methods), and iterating/refining as needed.
• Developing an activity diagram provides an overall view of the system's business processes.
• Use cases are scenarios for understanding system requirements and describe how the system is used.
• Use-case models encompass all use cases, with the development process following a defined flow.
• Use cases capture user needs and aid in project scheduling, analysis, design, implementation, and testing.
• A use case defines what happens in the system when it is performed, systematically identifying system uses and responsibilities.
• A use case involves a sequence of transactions yielding measurable value to an individual actor.
• Actors are users playing a role in the system, and all actors communicate with use cases.
• Measurable value means a use case helps the actor perform a task with identifiable value.
• A transaction is an atomic set of activities performed fully or not at all.
• Use associations occur when use cases share common subflows, allowing extraction into a separate use case.
• Extend associations are used when one use case is similar to another but more specialized.
• A fully developed use case description includes the name, scenario, triggering event, brief description, actors, related use cases, stakeholders, preconditions, and postconditions.
• Use case diagrams include actors, associations, and use cases with extension points.
• Use cases can be concrete (complete with initiation actors) or abstract (incomplete, used by concrete use cases).
• Actors represent the roles users play in the system.
• Consider roles rather than specific people or job titles when identifying actors.
• Actor candidates are identified by answering questions like who uses the system, who is affected by it, and which groups need help from the system.
• Also, consider who affects the system, which user groups are needed, what problems the application solves, and how users interact with the system.
• For each actor, determine the tasks and functions they should perform or that the system needs them to perform; then, name and briefly describe the use cases.
• Each use case should have only one main actor.
• Separate users from actors, actors from other actors, and use cases with different initiating actors and behaviors.
• Effective documentation serves as a communication tool among team members and provides an initial understanding of requirements.
• All documents should have a common cover sheet with the document's name, version, and responsible individual.
• The 80–20 rule suggests that 80% of the work can be done with 20% of the documentation, so ensure that 20% is easily accessible.
• Use a vocabulary that readers understand, focusing on communication rather than impressing with jargon.
• Make the document as short as possible by eliminating repetition, presenting summaries concisely, and using task-oriented chapter headings.
• Organize the document using established rules of good organization.
• The main goal of analysis is to capture a complete, unambiguous, and consistent picture of the system's requirements.
• Construct several models and views to describe what the system does rather than how it does it.
• Capturing use cases is a primary step in defining requirements.
• Every use case represents a potential requirement.
• Effective documentation requires eliminating repetition and presenting concise summaries and reviews.

Object Analysis: Classification

• OOA identifies classes that help achieve system goals.
• Classification checks if an object belongs to a category or class.
• An object is a unique, identifiable entity with operations and attributes.
• It possesses the know-how and information to perform its designed services.
• A class is a software template defining methods and variables for a type of object.
• It serves as a blueprint to create objects but does not occupy memory at runtime.
• Class is a template, an object is an instance.
• Object-oriented design involves incremental and iterative processes.
• A class specifies structure, behavior, and object descriptions.
• Classification focuses on identifying classes rather than individual objects.
• Intelligent classification is demanding and can seem arbitrary.
• An object can be categorized in multiple ways.
• Approaches for identifying classes include the noun phrase approach, common class patterns approach, use-case driven approach, and class responsibilities collaboration (CRC).
• The noun phrase approach involves reading use cases, interviews, and requirements to find noun phrases which are then categorized and refined.
• Irrelevant classes should be discarded, and each candidate class should have a clear statement of purpose.
• Look for nouns and noun phrases in the problem statement to identify classes.
• Some classes are implicit or taken from general knowledge but all classes must make sense in the application domain.
• Avoid computer implementation classes until the design stage.
• Redundant classes expressing the same information should be eliminated while adjective classes indicates a new class if the behavior of the object changes.
• Attribute classes used as values should be defined as attributes, not classes.
• Each class must have a purpose and be clearly defined as a necessary component
• Candidate classes are whittled down and modified to produce an initial class list for the system.
• Common class patterns are based on the knowledge of common classes proposed by researchers which includes:
• Events are points in time that must be recorded.
• Organizations are the units that people belong to.
• People and Person represent the different roles users play.
• Places are physical locations that the system must keep information about.
• Tangible Things and Devices are physical or groups of physical things.
• Concepts are intangible principles or ideas.
• In the use-case driven approach, scenarios are examined to determine necessary objects.
• Sequence and collaboration diagrams are further analyzed to identify objects and behaviors.
• Sequence Diagrams show object interactions arranged in time sequence.
• Collaboration Diagrams show object structure and message passing.
• CRC (Class, Responsibilities, and Collaborators) cards are used to identify classes and their responsibilities.
• The process involves iterating through identifying classes, assigning responsibilities, and identifying collaborations.
• Collaborations occur when an object requires assistance from other objects to fulfill its responsibilities.
• CRC cards contain all information for an object which starts with obvious cards while new objects are created to address any responsibility not already covered.
• Class names should be singular nouns that users are comfortable with and reflect the class's intrinsic nature.
• Class names must begin with an upper-case letter, and compound words should capitalize the first letter of each word.
• Finding classes is an incremental process, and it should be noted that there isn't a "right set of classes" but experience can improve the finding of classes..
• Unless starting with significant domain knowledge, there are probably more classes missing than will be eliminated.

Identifying Object Relationships, Attributes, and Methods

• Object relationships, attributes, and methods should be analysed.
• Objects collaborate to contribute to the system's behavior.
• In object-oriented environments, applications are the interactions and relationships among domain objects.
• All objects rely on others for services and controls through relationships.
• Three types of object relationships are association, super-sub structure (generalization hierarchy), and aggregation/a-part-of structure.
• Association involves a reference or dependency between two or more classes which can sometimes be implicit.
• Associations often appear as verbs in a problem statement and represent relationships between classes
• Common association patterns location (next to, part of), and communication (talk to, order to).
• Implementation-specific associations should be deferred to the design phase.
• Ternary or n-ary associations among more than two classes should be avoided and directed actions (derived) associations can be defined in terms of others so they should also be avoided.
• Superclass-subclass relationships place the most general class at the top of the hierarchy, with more specialized classes descending from it which are more specialized versions of their superclasses.
• Super–sub relationships are identified by noun phrases with adjectives.
• Only specialize sub-classes through significant behavior also known as top-down.
• Similar attributes or methods within classes can be grouped together, and common attributes and methods moved to a superclass which is also known as bottom-up.
• Attributes and methods shoyld be as high as possible in the hierarchy however you should not create very specialized classes.
• Excessive use of multiple inheritance should be avoided by inheriting from the most appropriate class and adding an object of another class as an attribute since it can be represented as an aggregation single inheritance and aggregation.
• A-part-of relationships, also known as aggregation, occur when a class consists of several component classes, the parts do not mean that the class behaves like its parts.
• Two major properties of a-part-of relationships are transitivity (if A is part of B, and B is part of C, then A is part of C) and antisymmetry (if A is part of B, then Bis not part of A)
• The part class must belong to the problem domain, be within the system's responsibilities, and provide a useful abstraction.
• If the part class captures more than a single value simply include it as an attribute with the whole class.
• A-part-of relationship patterns include assembly (physically exists), container (a course is considered a container for teachers), and collection-member (a soccer team is a collection of players).
• Identifying attributes and methods uses cases and UML diagrams.
• Class responsibility includes the use of being used, collaborating, and what it needs to know and remember.
• Each responsibility to the class that it logically belongs to for purpose and role.
• Attributes are information that the system needs to remember.
• Attributes usually correspond to nouns followed by possessive phrases.
• The class should be kept simple by only stating enough attributes to define the object's state.
• Omit derived attributes and drive attributes should be expressed as a method.
• Discovery of attributes shouldn't be carried to excess, and more attributes can be added in subsequent iterations.
• Methods and messages are workhorses using routines around every piece of data.
• Sequence diagrams assist in defining the services that objects must provide.
• Methods usually correspond to queries about attributes of the objects.
• Methods are responsible for managing the value of attributes such as query, updating, reading, and writing.
• Add methods that can maintain attributes, such as setting or getting prices.
• We learned how to identify three types of object relationships which include Association, Super-sub Structure, and A-part-of Structure.
• The hierarchical relation allows the sharing of properties through inheritance.
• Every class is responsible for storing certain information from domain knowledge and for performing operations necessary upon that information.