csce 431: midterm exam review. outline software engineering software lifecycle requirements...
Post on 31-Dec-2015
224 Views
Preview:
TRANSCRIPT
CSCE 431:Midterm Exam Review
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
Midterm Exam
• Thu 3/6 12:45-2:00pm
• Covers Introduction through Design Patterns
• Covers Homeworks 1 and 2
• Focus on material covered in slides
• Assigned readings are background material to aid your understanding
CSCE 431 Midterm Exam Review
Software Engineering
• Most large-scale software projects are challenged (over budget, behind schedule, scope reduced) or abandoned
• Most “successful” software still has issues
CSCE 431 Midterm Exam Review
Five Most Common Causes of Software Project Failure
• Unrealistic Schedules
• Inappropriate Staffing
• Changing Requirements During Development
• Poor Quality Work
• Believing in Magic
CSCE 431 Midterm Exam Review
No Silver Bullet
• Claim: no individual technology or practice will yield a 10-fold increase in productivity, reliability, simplicity in 10 years (from 1986)
• Further claim: substantial progress will be made over a longer period of time
• Both have proven true
• Yannis’s Law: “Programmer productivity doubles every 6 years”
CSCE 431 Midterm Exam Review
Software Engineering
• Bruegge et al Definition:• Software Engineering is a collection of techniques,
methodologies and tools that help with the production of a high-quality software system developed with a given budget before given deadline while change occurs.
• IEEE Definition:1. The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
2. The study of approaches as in (1).
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
Software Lifecycle
• Life of software from idea to deployed and maintained application
CSCE 431 Midterm Exam Review
Software Development Process
• No-Method Process• Sketch, code, debug, modify, repeat
• Waterfall Model• Requirements Design Implementation
Verification Maintenance• Sequential, inflexible, lots of documentation• Can include some feedback• Assumes requirements are complete
• V-Model Model• Testing a parallel activity to development
CSCE 431 Midterm Exam Review
SW Development Process (2)
• Evolutionary Model• Prototype, evaluate, then build
• Prototype Model• Prototype, evaluate, repeat until convergence
• Spiral Model• Iterate through waterfall model – 6-24 months• Generate succession of prototypes/versions• Continuous assessment of risk• Most successful approach for safety-critical
systems
CSCE 431 Midterm Exam Review
SW Development Process (3)
• Agile• Focus on schedule• Frequent cycles of code, build, test• Every build integrated all code from the cycle
• Stable, deliverable, partially-complete system
• Features• Refactoring• Continuous integration• Pair programming• Shared code• Coding standard• Common work space• Customer as part of team• Driven by user stories
CSCE 431 Midterm Exam Review
SW Development Process (4)
• More Agile features• Assume requirements specs will change during project
- ~50% of requirements done when project starts• But only change specs between development cycles
• Documents and code evolve together• Document with diagrams, e.g. UML
• Agile manifesto• Individuals and interactions >> processes and tools• Working SW >> comprehensive documentation• Customer collaboration >> contract negotiations• Responding to change >> following a plan
CSCE 431 Midterm Exam Review
SW Process Maturity
• Capability Maturity Model (CMM)1. Initial Level
• Also called ad hoc or chaotic, may require “heros”
2. Repeatable Level• Process at least documented
3. Defined Level• Process is institutionalized (sanctioned by management)
4. Managed Level• Quantitative, agreed upon metrics, provide feedback for resource
allocation (process itself does not change)
5. Optimizing Level• Process allows feedback of information to change the process itself
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
Requirements
• Large fraction of SW system problems due to incomplete/wrong requirements
• Requirement are statements of desired behavior for a system
• Requirements process has two activities:• Requirements elicitation — definition of the system
in terms understood by the customer and/or user• Requirements analysis — definition of the system in
terms understood by the developer
CSCE 431 Midterm Exam Review
Requirements Goals
• Understand the problem or problems that the eventual software system, if any, should solve
• Prompt relevant questions about the problem and system
• Provide basis for answering questions about specific properties of the problem and system
• Decide what the system should do
• Decide what the system should not do
• Ascertain that the system will satisfy needs of its stakeholders
• Provide basis for development of the system
• Provide basis for validation and verification (especially testing) of the system
CSCE 431 Midterm Exam Review
Requirements Components
• Domain properties• Assumptions that are true in the domain
• Functional requirements
• Non-functional requirements• Reliability• Security• Accuracy of results• Time and space performance• Portability• …
CSCE 431 Midterm Exam Review
Roles of Domain Properties vs. Requirements
• Requirement R:• “The database shall only be accessible to authorized
personnel”
• Domain Properties D:• Authorized personnel have passwords• Passwords are never shared with non-authorized personnel
• Specification S:• Access to the database shall only be granted after the user
enters an authorized password
• S, D R• But what if domain assumptions are wrong?
CSCE 431 Midterm Exam Review
Quality Goals for Requirements
• Correct
• Complete
• Consistent
• Unambiguous
• Traceable
• Modifiable
• Verifiable
• Prioritized
830-1998 — IEEE Recommended Practice for Software Requirements Specifications
CSCE 431 Midterm Exam Review
A Balancing Act
• One should not over-specify• == committing too early to a specific implementation
• One should not under-specify• == leaving some parts of the problem missing
CSCE 431 Midterm Exam Review
Requirements Example
• Study Naur’s example
• B. Meyer definition of specification:• Precise definition of the tasks to be performed by
the system
• Requirements are a natural-language definition of the system objectives
• Favor precise, falsifiable language over pleasant generalities!
CSCE 431 Midterm Exam Review
Seven Sins of Specifier
1. Noise• Irrelevant information, redundancy, remorse (restriction at use, not
definition, of an element)
2. Silence• Feature exists, but not discussed
3. Over-specification• Specification of a solution to the problem, not the problem
4. Contradiction
5. Ambiguity
6. Forward reference
7. Wishful thinking• Feature definition, for which candidate solutions cannot be
realistically validated
CSCE 431 Midterm Exam Review
Complete Requirements
• Definition from IEEE standard:
An SRS (Software Requirements Specification) is complete if, and only if, it includes the following elements:
• All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.
• Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.
• Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
CSCE 431 Midterm Exam Review
SRS Structure
1. Introduction1.1. Purpose1.2. Scope1.3. Definitions, acronyms, and abbreviations Glossary1.4. References1.5. Overview
2. Overall description2.1. Product perspective2.2. Product functions2.3. User characteristics2.4. Constraints2.5. Assumptions and dependencies
3. Specific requirements
Appendices
Index
CSCE 431 Midterm Exam Review
Requirements and Agile Methods
• Under XP (Extreme Programming)• Requirements are taken into account as defined at the particular time
considered• Requirements are largely embedded in test cases
• Benefits• Test plan will be directly available• Customer involvement
• Risks• Change may be difficult (refactoring)• Structure may not be right• Tests only cover the foreseen cases
• Possibly useful advise• Retain the best agile practices, in particular frequent iterations,
customer involvement, centrality of code and testing• Disregard those that contradict proven SE principles
CSCE 431 Midterm Exam Review
Techniques for Requirements Elicitation
• Questionnaires: Asking the end user a list of pre-selected questions
• Task Analysis: Observing end users in their operational environment
• Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system
• Use Cases: Abstractions that describe a class of scenarios
CSCE 431 Midterm Exam Review
Techniques for Requirements Elicitation
• Questionnaires: Asking the end user a list of pre-selected questions
• Task Analysis: Observing end users in their operational environment
• Scenarios: Describe the use of the system as a series of interactions between a specific end user and the system
• Use Cases: Abstractions that describe a class of scenarios
CSCE 431 Midterm Exam Review
Use Cases• The system treated as a “black box” (== the interactions
with system, including system responses, are as perceived from outside the system)
• Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals
• A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.
• Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain
• With some help from graphical notations, such as UML use case and sequence diagrams
CSCE 431 Midterm Exam Review
What is UML?
• UML == Unified Modeling Language
• Nonproprietary standard for modeling software systems, OMG
• Convergence of notations used in object-oriented methods• OMT (Object Modeling Technique, James Rumbaugh and colleagues)• Booch (Grady Booch)• OOSE (Ivar Jacobson)
• Current Version: UML 2.3 (May 2010)
• Information at the OMG portal http://www.uml.org
• Commercial tools:• Rational (IBM), Together (Borland), Visual Architect (business
processes, BCD)
• Open Source tools:• ArgoUML, BOUML, Dia,…
CSCE 431 Midterm Exam Review
UML Diagrams
CSCE 431 Midterm Exam Review
UML Diagrams
• Use case diagrams• Describe the functional behavior of the system as seen by the
user
• Class diagrams• Describe the static structure of the system: Objects, attributes,
associations
• Sequence diagrams• Describe the dynamic behavior between objects of the system
• Statechart diagrams• Describe the dynamic behavior of an individual object
• Activity diagrams• Describe the dynamic behavior of a system, in particular the
workflow
CSCE 431 Midterm Exam Review
Summary of Requirements
• Goal: SRS that describe the problem, not solution
• Variety of sources and means for eliciting requirements
• Use what makes most sense in the situation
• Variety of definition and specification techniques• Use what makes most sense in the situation
• Requirements should be validated (that they meet customer expectations)
• Specifications should be verified (that they satisfy requirements)
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
Software Configuration Management (SCM)
Software configuration management goals:• Configuration identification - identify configurations, configuration items and
baselines• Configuration control - implement controlled change process; e.g. change
control board to approve/reject change requests against a baseline• Configuration status accounting – record/report all necessary information on
status of development process• Configuration auditing – ensure configurations contain all intended parts and
are sound w.r.t. specifying documents, including requirements, architectural specs and user manuals
• Build management – manage process and tools used for system builds• Process management - ensure adherence to development process• Environment management – manage HW/SW that hosts the system• Teamwork – facilitate team interactions related to the process• Defect tracking – make sure every defect has traceability back to the sourcehttp://en.wikipedia.org/wiki/Software_configuration_management
CSCE 431 Midterm Exam Review
Why Separate Branches?
• Separation of concerns
• Less contention over the repository
• Groups commit according to common theme, allowing easier porting or roll-back
CSCE 431 Midterm Exam Review
Possible Branches
• Examples• Released versions• Soon-to-be-released versions• Ongoing development
• Ideas may never show up in a release, but you never know, so don’t flush the code
• Features or topics• Hotfixes
• Branch models are generally portable among version control systems
CSCE 431 Midterm Exam Review
Branch Model
CSCE 431 Midterm Exam Review
Main Branches• “master”
• Each commit is tagged with a version number
• Released versions of the product are built from this branch
• “develop”• Latest set of features that will go
into the next release• Always left in a functioning state
(no work in progress)• These branches live forever• Other supporting branches have
limited lifetimes
CSCE 431 Midterm Exam Review
Release Branches• “release-*”
• Whenever the “develop“ branch is feature-complete for the next release, create a release branch off of “develop“
• Only bugfixes or new metadata (like version numbers) may be committed
• This branch may periodically be merged into “develop“ to pass on the bugfixes
• When the release is complete:• Merge it into “master“ and tag• Merge it into “develop“ one last
time• Delete it
CSCE 431 Midterm Exam Review
Feature Branches
• “*” (any unique name)
• Whenever a developer wants to begin work on a new feature, bugfix, refactoring,… create a feature branch off of “develop“
• Try to break commits into their smallest, independent units
• When the feature is complete and will be included in the next release:
• Merge it into “develop“• Delete it
CSCE 431 Midterm Exam Review
Hotfix Branches• “hotfix-*”• Sometimes we make mistakes• Whenever we need an urgent fix
for a released version, create a hotfix branch off of “master“
• Treat it exactly like an unplanned release branch
• When a hotfix is complete:• Merge it into “master“ and tag• Merge it into “develop“• Delete it
• This model only supports hotfixes for the latest release
• If you want to support old versions after new ones have been released, then do not delete release branches
CSCE 431 Midterm Exam Review
Branch Model
CSCE 431 Midterm Exam Review
Configuration Management Summary
• Typical code development has graph-like dependencies
• Use version control systems to manage code
• Permits synchronization and consistency across developers
• Permits roll back to previous point in code history
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
From Requirements to Design
• S, D R• S = specification• D = domain properties• R = requirements
• Come up with a design that satisfies S
CSCE 431 Midterm Exam Review
Role of Object-Oriented Analysis
• Analysis object model later refines to object model
• Analysis object and dynamic models basis of system design
CSCE 431 Midterm Exam Review
Analysis
• Developers formalize requirements specification
• Examine exceptional cases, boundary conditions• Clients engaged
• OO Analysis• Developers build an object model of the application
domain• Extend model with how actors and system interact
with the application domain objects
CSCE 431 Midterm Exam Review
Basic Process of Class Design
• Iterate in some order, until convergence• Identify classes• Find attributes• Find operations• Find associations between classes
• Above too vague
• Some guidance exists
CSCE 431 Midterm Exam Review
Different Kinds of Objects
• Often the following categories can be identified• Suggested in: Jacobson, Booch, Rumbaugh: The Unified
Software Development Process. Addison-Wesley, 1999
• Entity objects• Represent the persistent information tracked by the system• Application domain objects, also called “Business objects”
• Boundary objects• Represent the interaction between the user and the system
• Control objects• Represent the control tasks performed by the system
• Somewhat related to a model-view-controller architecture
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
Sequence Diagrams
• Ties use cases with objects
• Shows how behavior of use case distributed among its participating objects
• More concise (and possibly more precise) than textual use case descriptions
CSCE 431 Midterm Exam Review
Sequence Diagrams: Notation• Each column represents an object
• Horizontal arrows are messages or stimuli
• Vertical rectangle is an activation of an operation• Length represents time of being active• Triggered by a message• Messages can originate from operations
• Time proceeds from top to bottom
• Lifetime also depicted• Objects on top row exist from start• Other objects created with «create» messages• Vertical dashed line expresses object’s life time
• Time span an object can receive messages
• Cross depicts destruction
CSCE 431 Midterm Exam Review
Sequence Diagram Conventions
• First column: initiating actor• Second column: boundary object• Third column: control object managing the rest of the
use case• Control objects created by boundary objects• Boundary objects created by control objects• Entity objects accessed by control and boundary objects• Entity objects never access control or boundary objects
• Entity objects stay reusable across use cases
CSCE 431 Midterm Exam Review
Example
CSCE 431 Midterm Exam Review
Example (cont.)
CSCE 431 Midterm Exam Review
State Machine Diagrams
• State machines represent a system’s behavior from a single object’s perspective
• (Sequence diagrams represent a system’s behavior from a single use case’s perspective)
• Cross-checking (which actions trigger which transitions) between both views useful
• Can reveal new use cases• Can reveal missing states• Can reveal ambiguities, incoherencies
CSCE 431 Midterm Exam Review
State Machine Diagrams: Notation
• Largely based on Harel’s statecharts (1987)
• Exactly like finite state machines, but features added to keep presentation manageable
• Not all states need to be shown simultaneously
• Can focus on one aspect of state independent of others
• Notation for nesting states and state machines (OR states)
• Orthogonal regions (AND states)
• Notation for triggers and actions
• Entry and exit actions
• Internal transitions
CSCE 431 Midterm Exam Review
Example
CSCE 431 Midterm Exam Review
Outline
• Software Engineering
• Software Lifecycle
• Requirements
• Configuration Management
• Object Oriented Design
• UML
• Design Patterns
CSCE 431 Midterm Exam Review
System Design• Subsystem decomposition
• Abstraction of the machine(s)• Choosing middleware, GUI frameworks, class
libraries, database engines
• Application domain components• Possibly choosing off-the-shelf application domain
components for select domain functionality
• Object design to fill in the rest• Adapt reusable components• Identify new solution classes• Specify subsystem interfaces precisely
CSCE 431 Midterm Exam Review
Object Design
• Purpose• Prepare for implementing the system model• Transform the system model for better
implementability/extensibility/performance/. . .
• Explore ways to implement the system model
• The result of object design should match the structure of the implementation
CSCE 431 Midterm Exam Review
Activities• Reuse: identify and adapt existing solutions
• Off-the-shelf components• Libraries• Design patterns
• Interface specification• Specs of each class interface• APIs of subsystems
• Object model restructuring• To improve some characteristics (extensibility,
understandability, etc.)
• Object model optimization• Greater speed, lower memory use, etc.
CSCE 431 Midterm Exam Review
Modularization
• Low coupling and high cohesion
• Minimize dependencies - changes localized
• Maximize unity - modules work well together
• Encapsulation – bundle data and methods, with access protection
• Enforce object invariants
• Inheritance – specification, implementation• Organization during analysis• Reuse during object design
CSCE 431 Midterm Exam Review
Modularization
• Open Closed Principle – class open for extension, closed for modification
• Liskov Substitution Principle – subclass can sub for base class
• Derived methods should expect no more and provide no less (pre- and post-conditions)
CSCE 431 Midterm Exam Review
Encapsulation
• BoochThe process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation
• Casual definition: bundling data and methods, with access protection
• Encapsulation enables object invariants to be enforced
CSCE 431 Midterm Exam Review
Inheritance
• Where used:
1. Organization (during analysis)• Inheritance helps in expressing generalization and
specialization in taxonomies that deal with the application domain
• Primary use: discussion with domain experts and customers
2. Reuse (during object design)• Inheritance helps in reusing models and code to deal
with the solution domain• Goal is to reduce redundancy and obtain extensibility• Primary use: developers
CSCE 431 Midterm Exam Review
Design Patterns Motivation
• Not every problem solved with a solution developed “from scratch”
• Desirable to reuse solutions
• Recording and cataloging experience in SW design often not done systematically, or at all
• Learning how to design starts by studying other designs
CSCE 431 Midterm Exam Review
Characterizing Design Patterns
• Reusable designs
• Capturing design knowledge that• Is too “high-level” to write as an abstraction in a library
• What is too high-level depends on the language, of course
• Modifiable abstractions/designs
• Basic idea: avoid “re-inventing the wheel”
• Capture well-tested solutions to oft-occurring situations
• Modularize design!
CSCE 431 Midterm Exam Review
Design PatternEach pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
Visually pleasing and practical structures for an application and/or setting could be described by a pattern language.
- Christopher Alexander• For example, desirable farmhouses in the Bernese
Oberland area of Switzerland used these patterns:North-South Axis Garden to the SouthWest-Facing Entrance Down the Slope Pitched RoofTwo Floors Half-Hipped EndHay Loft at the Back Balcony Toward the GardenBedrooms in Front Carved Ornaments
CSCE 431 Midterm Exam Review
23 Patterns in GoF Book
Creational Structural Behavioral
Factory Method Adapter Command
Abstract Factory Façade Visitor
Prototype Proxy Iterator
Builder Decorator Interpreter
Singleton Composite Mediator
Flyweight Memento
Bridge Observer
Strategy
Template Method
Chain of Responsibility
State
CSCE 431 Midterm Exam Review
Structure of a Design Pattern
• Four elements• A unique name• A problem description
• Situations in which the pattern applies• Problems addressed
• A solution• Stated as a set of collaborating classes and interfaces• Often uses class diagrams, sequence diagrams, state
charts, etc.
• A set of consequences that describes the trade-offs and alternatives w.r.t. the design goals the pattern addresses
CSCE 431 Midterm Exam Review
GoF Book’s Pattern Structure• Pattern Name and Classification• Intent
• “Why use this pattern?”
• Also known as• Motivation (Forces)
• Often an example scenario
• Applicability• Structure
• Often class and interaction diagrams
• Participants• Classes and objects involved, and their roles
• Collaborations• How classes/objects interact
• Consequences• Implementation• Sample Code
• Concrete example of how to use the pattern (in code)
• Known Uses• Related Patterns
CSCE 431 Midterm Exam Review
Composite Pattern: Motivation
There are times when a program needs to manipulate a tree data structure and it is necessary to treat both Branches as well as Leaf Nodes uniformly. Consider for example a program that manipulates a file system. A file system is a tree structure that contains Branches which are Folders as well as Leaf nodes which are Files. Note that a folder object usually contains one or more file or folder objects and thus is a complex object where a file is a simple object. Note also that since files and folders have many operations and attributes in common, such as moving and copying a file or a folder, listing file or folder attributes such as file name and size, it would be easier and more convenient to treat both file and folder objects uniformly by defining a File System Resource Interface.
CSCE 431 Midterm Exam Review
Composite Pattern: Intent
• The intent of this pattern is to compose objects into tree structures to represent part-whole hierarchies
• Composite lets clients treat individual objects and compositions of objects uniformly
CSCE 431 Midterm Exam Review
Composite Pattern: Implementation & Participants
Component Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
Leaf Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
Composite A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
Client The client manipulates objects in the hierarchy using the component interface. A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn’t matter if the node is a composite or a leaf.
CSCE 431 Midterm Exam Review
Composite Pattern: Applicability
• The composite pattern applies when there is a part-whole hierarchy of objects and a client needs to deal with objects uniformly regardless of the fact that an object might be a leaf or a branch
CSCE 431 Midterm Exam Review
Example – Graphics Drawing Editor
• In graphics editors a graphic can be basic or complex. Examples of simple graphics are lines and circles, where a complex graphic is a picture containing many simple (or complex) graphics. Since simple and complex shapes have operations in common, such as rendering the graphic to a screen, and since graphics follow a part-whole hierarchy, composite pattern can be used to enable the program to deal with all graphics uniformly.
CSCE 431 Midterm Exam Review
Example – Graphics Drawing Editor
In the example we can see the following actors:
Graphic (Component) Graphic is the abstraction for Line, Circle, etc. objects, (leafs) and Picture objects (composites).
Line, Circle (Leafs) Objects that have no children. They implement services described by the Graphic interface.
Picture (Composite) A Composite stores child Graphic objects in addition to implementing methods defined by the Graphic interface.
Client The Client (such as a graphical editor) manipulates Graphics in the hierarchy.
CSCE 431 Midterm Exam Review
Composite Pattern: Alternative Implementation
Some methods only make sense for Composite objects, such as Add, Remove, and getChild, and in the class diagram above are thus only defined for Composite objects. Prior to calling these methods, one has to cast a Component to a Composite. Alternatively, these methods could be defined in Component, with default implementations that would do nothing.
CSCE 431 Midterm Exam Review
Composite Pattern: Consequences
• The composite pattern defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed.
• Clients treat primitive and composite objects uniformly through a component interface which makes client code simple.
• Adding new components can be easy and client code does not need to be changed since client deals with the new components through the component interface.
CSCE 431 Midterm Exam Review
Composite Pattern: Related Patterns
• Decorator Pattern• Decorator is often used with Composite. When
decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.
CSCE 431 Midterm Exam Review
Composite Pattern: Known Uses
• File system implementation as discussed previously
• Graphics editors as discussed previously
CSCE 431 Midterm Exam Review
Observations
• Design patterns make use of interfaces, information hiding, polymorphism, indirection
• A pattern typically consists of several classes that may have complex associations
• Design patterns can thus make a design more complex, and decrease performance
• The tradeoff between added complexity and the potential pay-offs (modularity, extensibility, portability, etc.) needs to be considered
CSCE 431 Midterm Exam Review
Midterm Exam Summary
• Software Engineering – basic ideas
• Software Lifecycle – key examples, CMM
• Requirements – key issues, elicitation, good/bad practices, what you learned in HW1
• Configuration Management – why, branch diagrams
• Object Oriented Design – class design process, modularization
• UML – basic ideas for sequence, class design
• Design Patterns – what, why, know HW2 patterns
top related