chapter 6 (object-oriented systems analysis and design using UML) Flashcards

1
Q

Object-Oriented Analysis and Design

A
  • Works well in situations where complicated systems are
    undergoing continuous maintenance, adaptation, and
    design
  • Objects, classes are reusable
  • The Unified Modeling Language (UML) is an industry
    standard for modeling object-oriented systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Reusability

A

Recycling of program parts should reduce the costs of
development in computer-based systems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Maintaining systems

A

Making a change in one object has a minimal impact
on other objects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Object-Oriented Concepts

A
  • Objects
  • Classes
  • Inheritance
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Objects

A
  • Persons, places, or things that are relevant to the system
    being analyzed
  • May be customers, items, orders, and so on
  • May be GUI (graphical user interface) displays or text areas on a display
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Classes

A
  • Defines the set of shared attributes and behaviors found
    in each object in the class
  • Should have a name that differentiates it from all other
    classes
  • Instantiate is when an object is created from a class
  • An attribute describes some property that is possessed
    by all objects of the class
  • A method is an action that can be requested from any
    object of the class
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Inheritance

A
  • When a derived class inherits all the attributes and
    behaviors of the base class
  • Reduces programming labor by using common objects
    easily
  • A feature only found in object-oriented systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

CRC Cards and Object Think

A
  • CRC
    – Class
    – Responsibilities
    – Collaborators
  • CRC cards are used to represent the responsibilities of
    classes and the interaction between the classes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Interacting during a CRC Session

A
  • Identify all the classes you can
  • Create scenarios
  • Identify and refine responsibilities
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

The Unified Modeling Language (UML)
Concepts and Diagrams

A
  • Things
  • Relationships
  • Diagrams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Things

A
  • Structural things are:
    – Classes, interfaces, use cases, and other elements that provide
    a way to create models
    – They allow the user to describe relationships
  • Behavioral things
  • Describe how things work
    – Interactions and state machines
  • Group things
    – Used to define boundaries
  • Annotational things
    – Can add notes to the diagrams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Relationships

A
  • Structural relationships
    – Tie things together in structural diagrams
  • Behavioral relationships
    – Used in behavioral diagrams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Structural Relationships

A
  • Dependencies
  • Aggregations
  • Associations
  • Generalizations
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Behavioral Relationships

A
  • Communicates
  • Includes
  • Extends
  • Generalizes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Structural diagrams

A

Used to describe the relation between classes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Behavioral diagrams

A

Used to describe the interaction between people
(actors) and a use case (how the actors use the system)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Structural Diagrams

A
  • Class diagrams
  • Object diagrams
  • Component diagrams
  • Deployment diagrams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Behavioral Diagrams

A
  • Use case diagrams
  • Sequence diagrams
  • Collaboration diagrams
  • Statechart diagrams
  • Activity diagrams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Commonly Used UML Diagrams
Use case diagram

A

– Describing how the system is used
– The starting point for UML modeling

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Use case scenario

A

A verbal articulation of exceptions to the main
behavior described by the primary use case

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Activity diagram

A

Illustrates the overall flow of activities

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Sequence diagrams

A

Show the sequence of activities and class relationships

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Class diagrams

A

Show classes and relationships

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Statechart diagrams

A

Show the state transitions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Use Case Modeling

A
  • Describes what the system does, without describing how
    the system does it
  • Based on the interactions and relationships of individual
    use cases
  • Use case describes
    – Actor
    – Event
    – Use case
26
Q

Activity Diagrams

A
  • Show the sequence of activities in a process, including
    sequential and parallel activities, and decisions that are made
  • Symbols
    – Rectangle with rounded ends
    – Arrow
    – Diamond
    – Long, flat rectangle
    – Filled-in circle
    – Black circle surrounded by a white circle
    – Swimlanes
27
Q

Creating Activity Diagrams

A
  • Created by asking what happens first, what happens
    second, and so on
  • Must determine what activities are done in sequence or in
    parallel
  • The sequence of activities can be determined from
    physical data flow diagrams
  • Can be created by examining all the scenarios for a use
    case
28
Q

Swimlanes

A
  • Useful to show how the data must be transmitted or
    converted
  • Help to divide up the tasks in a team
  • Makes the activity diagram one that people want to use to
    communicate with others
29
Q

Activity Diagrams and Test Plans

A
  • Activity diagrams may be used to construct test plans
  • Each event must be tested to see if the system goes to
    the next state
  • Each decision must be tested
30
Q

Use an activity diagram when:

A

– It helps to understand the activities of a use case
– The flow of control is complex
– There is a need to model workflow
– When all scenarios for a use case need to be shown

31
Q

Sequence Diagrams

A
  • Illustrate a succession of interactions between classes or
    object instances over time
  • Often used to show the processing described in use case
    scenarios
  • Used to show the overall pattern of the activities or
    interactions in a use case
32
Q

Communication Diagrams

A
  • Describes the interactions of two or more things in the
    system that perform a behavior that is more than any
    one of the things can do alone
  • Shows the same information as a sequence diagram,
    but may be more difficult to read
  • Emphasizes the organization of objects
  • Made up of objects, communication links, and the
    messages that can be passed along those links
33
Q

Class Diagrams

A
  • Show the static features of the 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
  • Attributes
    – Private
    – Public
    – Protected
  • Methods
    – Standard
    – Custom
34
Q

Method Overloading

A
  • 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
35
Q

Types of Classes

A
  • Entity classes
  • Interface classes
  • Abstract classes
  • Control classes
36
Q

Entity Classes

A
  • Represent real-world items
  • The entities represented on an entity-relationship
    diagram
37
Q

Interface or Boundary Classes

A
  • Provide a means for users to work with the system
  • Human interfaces may be a display, window, Web form,
    dialogue box, touch-tone telephone, or other way for
    users to interact with the system
  • System interfaces involve sending data to or receiving
    data from others
38
Q

Abstract Classes

A
  • Linked to concrete classes in a
    generalization/specialization relationship
  • Cannot be directly instantiated
39
Q

Control Classes

A
  • Used to control the flow of activities
  • Many small control classes can be used to achieve
    classes that are reusable
40
Q

Sequence diagrams may be discussed using three
layers:

A

– 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

41
Q

Defining Messages and Methods

A
  • 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
42
Q

Create Sequence Diagrams

A
  • 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
43
Q

Creating a Test Plan from a Sequence Diagram

A
  • 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
44
Q

The connections between classes

A

– Associations
– Whole/part

45
Q

Associations

A
  • The simplest type of relationship
  • Association classes are those that 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
46
Q

Whole/Part Relationships

A
  • When one class represents the whole object, and other
    classes represent parts
  • Categories
    – Aggregation
    – Collection
    – Composition
47
Q

Aggregation

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

Collection

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

Composition

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

Generalization/Specialization Diagrams

A
  • Generalization
  • Inheritance
  • Polymorphism
  • Abstract classes
  • Messages
51
Q

Generalization

A
  • Describes a relationship between a general kind of thing
    and a more specific kind of thing
  • Described as an “is a” relationship
  • Used for modeling class inheritance and specialization
  • General class is a parent, base, or superclass
  • Specialized class is a child, derived, or subclass
52
Q

Inheritance

A
  • Helps to foster reuse
  • Helps to maintain existing program code
53
Q

Polymorphism

A
  • The capability of an object-oriented program to have
    several versions of the same method with the same
    name within a superclass/subclass relationship
  • The subclass method overrides the superclass method
  • When attributes or methods are defined more than once,
    the most specific one is used
54
Q

Abstract Classes

A
  • Abstract classes are general classes
  • No direct objects or class instances, and is only used in
    conjunction with specialized classes
  • Usually have attributes and may have a few methods
55
Q

Finding Classes

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

Determining Class Methods

A
  • Standard methods
  • Examine a CRUD matrix
57
Q

Messages

A
  • 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
58
Q

Statechart Diagrams

A
  • Used to examine the different states that an object may have
  • Created for a single class
    – Objects are created, go through changes, and are deleted
    or removed
  • Objects
  • States
  • Events
    – Signals or asynchronous messages
    – Synchronous
    – Temporal events
59
Q

statechart diagrams created when:

A

– A class has a complex life cycle
– An instance of a class may update its attributes in a
number of ways through the life cycle
– A class has an operational life cycle
– Two classes depend on each other
– The object’s current behavior depends on what
happened previously

60
Q

Packages

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

The steps used in UML are:

A

– Define the use case model
– Continue UML diagramming to model the system
during the systems analysis phase
– Develop the class diagrams
– Draw statechart diagrams
– Begin systems design by refining the UML diagrams
– Document your system design in detail