Systems Analysis & Design Chapter 10

Object-Oriented Systems Analysis and Design

• Object-oriented systems analysis and design is suited for complex systems that require continuous maintenance, adaptation, and design.
• It allows for the reuse of objects and classes, reducing development costs.

Object-Oriented Concepts

• Objects: Represent persons, places, or things relevant to the system, e.g., customers, items, orders, GUI displays.
• Classes: Define the set of shared attributes and behaviors found in each object, e.g., a class "Vehicle" with attributes "color" and "model".
• Inheritance: A derived class inherits all the attributes and behaviors of the base class, reducing programming labor and promoting reuse.

CRC Cards and Object Think

• CRC Cards: Represent classes and their interactions, with columns for Class, Responsibilities, and Collaborators.
• Object Think: A way of thinking about objects and their interactions, used to identify classes and their responsibilities.

Unified Modeling Language (UML)

• Things: Structural things (classes, interfaces, use cases), behavioral things (interactions, state machines), grouping things (packages), and annotational things (notes).
• Relationships: Structural relationships (dependencies, aggregations, associations, generalizations) and behavioral relationships (communicates, includes, extends, generalizes).
• Diagrams: Structural diagrams (class diagrams, object diagrams, component diagrams, deployment diagrams) and behavioral diagrams (use case diagrams, sequence diagrams, communication diagrams, statechart diagrams, activity diagrams).

Use Case Modeling

• Use Cases: Describe what a system does, without describing how the system works, from the user's perspective.
• Use Case Diagrams: Show the relationships between actors, use cases, and systems.
• Use Case Scenarios: Describe the steps performed in a use case, including preconditions, postconditions, assumptions, and variations.

Activity Diagrams

• Activity Diagrams: Show the sequence of activities in a process, including sequential and parallel activities, and decisions.
• Symbols: Use specialized symbols, such as rectangles, arrows, diamonds, and swimlanes, to represent activities and flows.

Sequence Diagrams

• Sequence Diagrams: Illustrate the succession of interactions between classes or object instances over time.
• Symbols: Use specialized symbols, such as lifelines, messages, and activations, to represent interactions and time ordering.

Other Key Concepts

• Scope: Defines the boundaries of a system, including what is in or outside the system.
• Use Case Relations: Describe the relationships between use cases, including communicates, includes, extends, and generalizes.
• Developing Use Cases: Involves identifying actors, use cases, and scenarios, and creating use case diagrams and scenarios.### Communication Diagrams
• Show the interactions between two or more objects in a system
• Emphasize the organization of objects rather than the time ordering
• Made up of objects, communication links, and the messages that can be passed along those links

Class Diagrams

• Show the static features of a system and do not represent any particular processing
• Show the nature of the relationships between classes
• Show data storage requirements as well as processing requirements
• Classes:
  • Have attributes (private, public, protected)
  • Have methods (standard, custom)
• Example: Class diagram for Course Offerings shows aggregation and whole-part relationships

Method Overloading

• Including the same method (or operation) several times in a class
• The same method may be defined more than once in a given class, as long as the parameters sent as part of the message are different

Types of Classes

• Entity classes: Represent real-world items
• Interface classes: Provide a means for users to work with the system
• Abstract classes: Linked to concrete classes in a generalization/specialization relationship
• Control classes: Used to control the flow of activities

Layers

• Sequence diagrams may be discussed using three layers:
  • Presentation layer: What the user sees, corresponding to the interface or boundary classes
  • Business layer: Containing the unique rules for this application, corresponding roughly to control classes
  • Persistence or data access layer: For obtaining and storing data, corresponding to the entity classes

Defining Messages and Methods

• Each message may be defined using a notation similar to that described for the data dictionary
• The methods may have logic defined using structured English, a decision table, or a decision tree

Creating Sequence Diagrams

• Include the actor from the use case diagram
• Define one or more interface classes for each actor
• Each use case should have one control class
• Examine the use case to see what entity classes are required
• The sequence diagram may be modified when doing detailed design

Creating a Test Plan from a Sequence Diagram

• Does each method return correct results?
• Ensure that entity classes store or obtain the correct attribute values
• Verify that all JavaScript paths work correctly
• Ensure that the server control classes work correctly
• Ask, “What may fail?”
• Determine what to do if something can fail

Relationships

• The connections between classes
• Types of relationships:
  • Associations
  • Whole/part

Associations

• The simplest type of relationship
• Association classes are used to break up a many-to-many association between classes
• An object in a class may have a relationship to other objects in the same class, called a reflexive association

Whole/Part Relationships

• When one class represents the whole object, and other classes represent parts
• Categories:
  • Aggregation
  • Collection
  • Composition

Aggregation

• A “has a” relationship
• Provides a means of showing that the whole object is composed of the sum of its parts

Collection

• Consists of a whole and its members
• Members may change, but the whole retains its identity
• A weak association

Composition

• The whole has a responsibility for the parts, and is a stronger relationship
• If the whole is deleted, all parts are deleted

Generalization/Specialization Diagrams

• Generalization: Describes a relationship between a general kind of thing and a more specific kind of thing
• Inheritance: Helps to foster reuse and maintain existing program code
• Polymorphism: The capability of an object-oriented program to have several versions of the same method with the same name within a superclass/subclass relationship
• Abstract classes: General classes, no direct objects or class instances, and is only used in conjunction with specialized classes

Finding Classes

• During interviewing or JAD sessions
• During facilitated team sessions
• During brainstorming sessions
• Analyzing documents and memos
• Examining use cases, looking for nouns

Determining Class Methods

• Standard methods
• Examine a CRUD matrix

Messages

• Used to send information by an object in one class to an object in another class
• Acts as a command, telling the receiving class to do something
• Consists of the name of the method in the receiving class, as well as the attributes that are passed with the method name
• May be thought of as an output or an input

Statechart Diagrams

• Used to examine the different states that an object may have
• Created for a single class
• Objects:
  • Created, go through changes, and are deleted or removed
• States:
  • Different conditions that an object can be in
• Events:
  • Signals or asynchronous messages
  • Synchronous
  • Temporal events

Packages

• Containers for other UML things
• Show system partitioning
• Can be component packages
• Can be physical subsystems
• Use a folder symbol
• May have relationships

This quiz covers object-oriented systems analysis and design using UML, based on the 11th edition of the Systems Analysis & Design book.