Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key

image

Play button

image

Play button

image

Progress

1/31

Click to flip

31 Cards in this Set

  • Front
  • Back

Data Abstractions –

attributes

Procedural Abstractions –

– operations, methods or serviceso Algorithms that process the data

Objects interact

through messages

Encapsulation

Information hidingo Component reuseo Interfaces are simplified Less parameters passed Coupling is reduced

Inheritance reuse accomplished directly

o Subclass inherits all data and operations with no further worko Changes are made to base class they are immediately propagatedthrough the systemo At each level new attributes and operations can be added

Refactoring

Change the internal structure of a program without changing itsfunctionalityo Used to combat software entropy Law of increasing complexity, law of decreasing quality, etco Separate refactoring work from adding functionalityo Refactor when old code “gets in the way” or can’t understand codeo Thoroughly test refactored code

Developing a class

From scratch Inherit from an existing classo Possibly adding features Class hierarchy can be restructured Override existing operationso Polymorphism

Advantages of OO Developed Systems

Lead to reuse Leads to faster developed programs with higher quality More used, reused the better its tested and understood Easier to maintain Structure is inherently decoupledLeads to fewer side effects when changed Easier to adapt and scale Assembled of reusable parts (subsystems)

UML

5 views of the system User Model Viewo Users perspectiveo Use–Case diagram and scenarios Structural model view o Classes, objects and relationships Behavioral Model Viewo Dynamic or behavioral aspectso Interaction or collaboration between structural elements Implementation Viewo How they are to be built Environmental Viewo User Interface

Process

Use Cases Determine classes, responsibilities, and collaborators – CRC Cards Define structures and hierarchieso Generalization/specializationo Composite, aggregate Define subjects and subsystemso A group of classes that collaborate among themselves to accomplish aset of cohesive taskso Provide a contract of the responsibilities that can be expected of them Define object – relationship modelo Class diagram – cardinalityo To derive Using CRC cards determine the network of collaborators Give name and direction to the network Determine cardinality Define behavior modelo Model the dynamic behavioro Go through the Use Cases documenting events where information hasbeen exchangedo Build State transition diagram

OOA -> OOD

CRC responsibilitiesUse Cases subsystemObject –relationship message designObject-behavioral subsystem

System Design Activities

ystem Design Activities Partition the analysis model into subsystems which share something incommono Classes which only collaborate with each othero All accomplish same functiono All are on same piece of hardwareo Manage a set of resources Concurrency and Subsystem Allocationo Concurrent only if classes are active at the same timeo Either apply them to separate processors or a single processor usingconcurrency User Interfaceo Use caseso Subsystems to determine menus Data Management Componento Design attributes and management operationso Determine file/database system Inter-subsystem Collaboration

OOA – Static Modeling

• Determine classes, attributes and methods (operations/responsibilities)• Form basis of OO paradigm– Use Cases– Class network• Three types of classes– Entity class: models information that is long lived (persistent when the systemis idle)– Boundary Class: models the interaction between the software product and itsactors (UI – both input and output)– Control Class: models complex computations and algorithms

Extracting Classes

• Functional modeling – Present scenarios for all of the use cases• Entity Class modeling – determine the entity classes and their attributes• Dynamic modeling – determine the operations performed by each entity class• Done iteratively and incrementally

Identifying Entity Classes

Grammatical parse on use-case text or processing narratives• Nouns or noun clauses• Look for– External entities• Produce or consume information– Things• Reports or displays, etc.– Occurrences or events– Roles– Places – establish context– Structures

Coad/Yourdon selection criteria

Satisfy almost all of these– Retained info– Needed service– Multiple attributes– Common attributes– Common operations Essential requirements

• Rumbaugh – reasons to reject

• Vague• Attribute• Redundant• Irrelevant• Implementation

Define Operations

Manipulate– Perform calculation– Inquire about state– Monitor for a controlling event– Verbs in the grammatical parse

Associations and Dependencies

• Relationships between classes– Multiplicity – the number of possible instances of the class associated with asingle instance of the other class.

Multiplication Meaning

0..1 Zero or 1 instance (n..m)0..* or * Zero or many1 Exactly 1 instance1..* At least one instance

• Association

– binary relationship between two entity classes. There is anassociation if an instance in one class must know about the other to do its work.

– Generalization

– denotes inheritance with one class being the super class ofthe other, denoted by a triangle pointing to the super class

Aggregation –

one class belongs to a collection, denoted by a diamondpointing to the class containing the whole

Composition

– a stronger association in which the whole is made up of theparts, the parts cannot exist without the whole, denoted by a filled diamond atthe whole

Analysis Packages

• Categorize the classes into units of corresponding nature• Package diagram• Object Diagram• Component Diagram• Deployment Diagram

Static Aspects

• Define classes, their relationships and their behaviors• Define class– Attributes– Methods (behaviors/operations/responsibilities)• Define class hierarchy

Dynamic Modeling

• Use case diagram• Interaction Diagrams– Sequence diagram– Collaboration Diagram• Statecharts• Activity Diagrams– Swimlane Diagrams

Interaction Diagrams

• Develop use-case(s)/scenarios and use-case diagram• Describe how objects collaborateClasses and actors from the use case and class diagrams participate to model theinteractions to carry out a use case• Two types– sequence and collaboration– Sequence – detail how operations are carried out• What messages are sent and when• Timing is important– Collaboration – detail how operations are carried out• Focus on objects roles and do not include timing

Heuristics for drawing Sequence Diagrams

・ First column should correspond to the actor who initiates the use case・ The second column should be a boundary objects that the actor uses toinitiate the use case・ The third column should be the control object that manages the rest of theuse case・ Control objects are created by boundary objects initiating use cases・ Entity objects are accessed by control and boundary objects・ Entity objects never access boundary or control objects, this makes it easierto share entity objects across use cases

UML Activity diagram

– Also supplements use-cases– Provides graphical representation of the flow of the interaction– Symbols• Rounded rectangles – system function• Directed arcs – flow through the system• Diamond – branching decision• Horizontal lines – parallel activities– Adds more information by including constraints explicitly

UML Swimlane Diagram

– Adds actor responsibility to activity diagram when multiple actors areinvolved in a use case– Partition the diagram into areas for each actor involved and place theirfunctionality in their partition