Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
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 |
