csc 205 software engineering i 1 overview - design introduction to design review of architectural...
Post on 21-Dec-2015
215 views
TRANSCRIPT
![Page 1: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/1.jpg)
CSC 205 Software Engineering I
1
Overview - Design
• Introduction to Design• Review of Architectural Design• Modules• Structured Design• Objects• Object-Oriented Design • Detailed Design• Integration Testing
![Page 2: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/2.jpg)
CSC 205 Software Engineering I
2
Goals and Objectives
• Develop a coherent representation of a software system that will satisfy the requirements
• Identify inadequacies in the requirements• Develop review plan that demonstrates
coverage of the requirements– yields confidence in design
• Develop test plan that covers design – yields confidence in both design and
implementation
![Page 3: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/3.jpg)
CSC 205 Software Engineering I
3
Introduction to Design
RequirementsChange
Validation
Revalidation
Validation
Verification
Testing
Requirements Analysis +Specification
DesignHow ?
Operation andMaintenance
Implementation andIntegration
![Page 4: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/4.jpg)
CSC 205 Software Engineering I
4
Relationship to other lifecycle phases
• Requirements– Specifies the “what” not the “how”– Provides conceptual boundaries
¤ keeps design focused
• Implementation– Design stops and coding begins when design
specifications are sufficient for coding assignments
¤ each assignment, theoretically, can be given to a programmer unaware of the overall system architecture
![Page 5: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/5.jpg)
CSC 205 Software Engineering I
5
Basic Design Process
• The design process develops several models of the software system at different levels of abstraction– Starting point is an informal “boxes and arrows” design– Add information to make it more consistent and
complete– Provide feedback to earlier designs for improvement
Informaldesignoutline
Informaldesign
More formaldesign
Finisheddesign
![Page 6: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/6.jpg)
CSC 205 Software Engineering I
6
Top-Down Design
• Recursively partition a problem into sub-problems until tractable (solvable) problems are identified
System level
subsystem level
module level
![Page 7: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/7.jpg)
CSC 205 Software Engineering I
7
Design Activities
• Architectural design– Subsystem identification
¤ services and constraints are specified
– Module design¤ modular decomposition is performed; relationships specified
• Detailed design– Interface design
¤ module interfaces are negotiated, designed and documented
– Data structure and algorithm design¤ module details (data structures and algorithms) to provide
system services are specified
![Page 8: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/8.jpg)
CSC 205 Software Engineering I
8
Design Products
• Refined requirements specification• Description of systems to be constructed
– software architecture (diagram)– modular decomposition (hierarchy)– abstract module interface specifications– detailed module designs
• Documentation of decisions and rationale• Data dictionary of all defined objects• Validation review plan• Integration test plan
![Page 9: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/9.jpg)
CSC 205 Software Engineering I
9
Desirable Characteristics/ Common Problems• Uniform• Complete• Rigorous • Confirmable,
verifiable, testable• Supportable by tools• Desensitized to
change• Accommodates
independent coding
• Depth-first design: only partial satisfaction of requirements
• Failure to consider potential changes
• Too detailed: overly constrains implementation
• Ambiguous: misinterpreted during implementation
• Undocumented: designers become essential
• Inconsistent: system cannot be integrated
![Page 10: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/10.jpg)
CSC 205 Software Engineering I
10
Architectural Design
• Architectural Design – decomposition of large systems that provide some related
set of services + establishing a framework for control and communication
• Architectural styles establish guidelines – a relatively new area of research
• No generally accepted architectural design process – some important sub-processes
¤ System structuring: structuring of the system into a number of subsystems, where a subsystem is an independent software unit
¤ Control modeling: establishing a general model of control relationships between the parts of the system
¤ Modular decomposition: decomposing each identified subsystem into modules
![Page 11: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/11.jpg)
CSC 205 Software Engineering I
11
Software Architecture
• Components– The elements out of which the system is built– Examples: filters, databases, objects, ADTs
• Connectors– The interaction or communication mechanisms– The glue that combines the components– Examples: procedure calls, pipes, event
broadcast, messages, secure protocols
• Constraints– Limitations on the composition of components and
connectors
![Page 12: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/12.jpg)
CSC 205 Software Engineering I
12
Architectural Style
• Example architectural styles– Batch sequential– Pipe and filter– Main program and subroutines– Blackboard– Interpreter– Client-server– Communicating processes– Event systems– Object-oriented– Layered Systems
Families of systems defined by patterns of composition
![Page 13: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/13.jpg)
CSC 205 Software Engineering I
13
Architectural Design:System Structuring• Model of the system structure and decomposition
¤ how subsystems share data¤ how they are distributed¤ how they interface with each other
• Three standard models– Repository model: how subsystems exchange and share
information• E.g., all shared data is held in a central database or each sub-system
maintains its own database
– Distribution model: how data and processing is distributed across a range of processors
• E.g., Client-server or peer-to-peer processes
– Abstract machine model: the interfacing of subsystems as abstract machines each of which provides a set of services to others
• E.g., each subsystem defines an abstract machine
![Page 14: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/14.jpg)
CSC 205 Software Engineering I
14
Architectural Design:Control Modeling• Control of subsystems so that services are
delivered to the right place at the right time• Two general approaches
– Centralized control¤ One subsystem has overall responsibility for control and
starts/stops other subsystems• call-return model (sequential)• manager model (concurrent)
– Event-based control¤ each subsystem responds to externally generated events
(from other subsystems or the environment)• broadcast model• interrupt-driven model
![Page 15: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/15.jpg)
CSC 205 Software Engineering I
15
Architectural Design:Modular decomposition• After decomposition of the system into subsystems,
subsystems must be decomposed into modules– No rigid distinction between system and modular decomposition
• Two important approaches for decomposing subsystems into modules:
– Data-flow (structured design)¤ system is decomposed into functional modules which accept input data
and transform it to output data ¤ process-based decomposition¤ achieves mostly procedural abstractions
– Object-oriented (object-oriented analysis and design)¤ system is decomposed into a set of communicating objects¤ object-based decomposition¤ achieves both procedural + data abstractions
![Page 16: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/16.jpg)
CSC 205 Software Engineering I
16
Architectural Design:Hierarchy• Hierarchies support modular decomposition
– Uses relation: a uses b only if the correct functioning of a depends on the existence of a correct implementation of b
¤ modular decomposition can be specified by uses, where• Level 0 is the set of all programs that use no other program• Level i ( i > 0) is the set of all programs that use at least one
program on level i -1 and no program at level ≥ i.• Note: the uses relation does not always provide a hierarchy
– Is-composed-of relation: a is-composed-of b if b is a component of a and encapsulated within a
¤ modular decomposition can be specified by is-composed-of, where• non-terminals are virtual code• terminals are the only units represented by code• Then, the uses relation is specified over the set of terminals only• Note: the is-composed-of relation is acyclic
![Page 17: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/17.jpg)
CSC 205 Software Engineering I
17
Modules
• Definition: a software entity encapsulating the representation of an abstraction and providing an abstract interface to it
• Module interaction– Module hides implementation details so that the rest of the
system is insulated and protected from the details AND vice versa– Modules communicate only through well-defined interfaces
• Negotiating module interfaces– design interface to component to be insensitive to change– determine likely usage patterns and purposes– disseminate minimal information as useful generalities
¤ abstract Interfaces: one specification, many possible implementations
– suppress unnecessary detail of a design decision
![Page 18: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/18.jpg)
CSC 205 Software Engineering I
18
Architecture, Subsystems and Modules • Architecture consists of interacting subsystems
– determined by application domain
• Subsystems– a component whose operation does not depend on the
services provided by other subsystems– communicates with other subsystems via defined
interfaces– is decomposed further into modules by design methods
• Modules– a component that provides one or more services to
other modules– not normally considered an independent subsystem
![Page 19: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/19.jpg)
CSC 205 Software Engineering I
19
Modular Decomposition:Abstraction• Abstraction is a tool that supports focus on important,
inherent properties and suppression of unnecessary detail– permits separation of conceptual aspects of a system from the
implementation details– allows postponement of design decisions
• Three basic abstraction mechanism– procedural abstraction
¤ specification describes input/output¤ implementation describes algorithm
– data abstraction¤ specification describes attributes, values, properties, operations¤ implementation describes representation and implementation
– control abstraction¤ specification describes desired effect¤ implementation describes mechanism
![Page 20: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/20.jpg)
CSC 205 Software Engineering I
20
Modular Decomposition:Information Hiding• Information hiding is a decomposition principle that
requires that each module hides its internal details and is specified by as little information as possible– forces design units to communicate only through well-
defined interfaces– enables clients to be protected if internal details change
• Sample entities to encapsulate– abstract data types– algorithms– input and output formats– processing sequence– machine dependencies– policies (e.g. security issues, garbage collection, etc.)
![Page 21: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/21.jpg)
CSC 205 Software Engineering I
21
Modular Decomposition:Cohesion and Coupling
• Cohesion– the degree to which the internals of a module are
related
• Coupling– the degree to which the modules of a design are
related
• The ideal system has highly cohesive modules that are loosely coupled– high cohesion -> well-designed reusable module– low coupling -> coherent design, resistant to
change
![Page 22: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/22.jpg)
CSC 205 Software Engineering I
22
Types of Cohesion
• coincidental– multiple, completely unrelated actions
• logical– series of related actions, often selected by parameters
• temporal– series of actions related in time
• procedural– series of actions sharing sequence of steps
• communicational– procedural cohesion but on the same data
• informational– series of independent actions on the same data
• functional: exactly one action (Good)
(Bad)
![Page 23: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/23.jpg)
CSC 205 Software Engineering I
23
Types of Coupling
• content– one module directly references content of another
• common– both modules have access to same global data
• control– one module passes an element of control to another
• stamp– one module passes a data structure to another;
which only uses part of the passed information
• data– one module passes only homogeneous data items
(Good)
(Bad)
![Page 24: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/24.jpg)
CSC 205 Software Engineering I
24
Some examples of cohesion
• Logical cohesion– Input/Output libraries– Math libraries
• Temporal cohesion– Program initialization
• Communicational cohesion– “calculate data and write it to disk”– Closely related: sequential cohesion
¤ the output of one element is the input to another
![Page 25: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/25.jpg)
CSC 205 Software Engineering I
25
Some examples of coupling
• Control coupling– One module passes control flags (parameters or
global variables) that control the sequence of processing steps in another module
• Stamp coupling (alternative definition)– Similar to common coupling (modules that share
global data) except that globals are shared selectively among routines that require the data
– Ada packages support stamp coupling since variables defined in a package specification are shared between all modules which use the package.
![Page 26: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/26.jpg)
CSC 205 Software Engineering I
26
Structured Design
• System is completely specified by the functions that is to perform– Top-down, iterative refinement of functionality
¤ break the [system] function into subfunctions¤ determine hierarchy and data interaction
– Function refinement guides data refinement– Hierarchical organization is a tree with one module per
subfunction
• Pros and Cons– modules are highly functional– best suited when state information is not pervasive– data decisions must be made earlier– changes in data ripple through entire structure– little chance for reusability
![Page 27: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/27.jpg)
CSC 205 Software Engineering I
27
Structured Design Process
• Identify flow of data and incorporate detail and structure iteratively– given specification loop
¤ identify data flow and transformations• nouns as data, verbs as transformations
¤ derive data flow diagrams¤ identify "natural aggregates"
• identify highest level input and output units• remaining units are central transforms• form level of structure chart• control module (coordinate)
– input module (afferent)– central module(s) (transform)– output module (efferent)
• form structure chart
– until implementation is immediate
![Page 28: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/28.jpg)
CSC 205 Software Engineering I
28
Data Flow Diagrams
•Software system as flow of data from logical processing unit A (transformation) to B
– do not include control information– data flow diagram elements
¤ round-cornered rectangle = transformation¤ vector = data flow¤ vector operation = data flow link
• * (and) • + (or)• + (exclusive or)
¤ arc with data flow link = bracketing to override precedence
• and over or over exclusive or
¤ rectangle = data store¤ circle = user interaction (input/output)
![Page 29: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/29.jpg)
CSC 205 Software Engineering I
29
Data Flow Templates
+
+
*A
A
A
B
B
B
C
C
Cconjunct
disjunct
exclusive
*
+
+A
A
A
A
B
C
B
B
C
C
C
simple
conjunct
disjunct
exclusive
![Page 30: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/30.jpg)
CSC 205 Software Engineering I
30
Structure Charts
•Depict software structure as a hierarchy of modules and data communication
– may have control info defining selection and loops
– structure chart elements ¤ rectangle = module¤ four types of module based on data flow
• control (coordinate)• input (afferent)• central (transform)• output (efferent)
![Page 31: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/31.jpg)
CSC 205 Software Engineering I
31
Structure Charts (cont’d)
¤ vector = control relationship¤ arrow with circular tail = directed data relationship
• data couple (open), control couple (closed)
¤ round-cornered rectangle = data store¤ circle = user interaction (input/output)
![Page 32: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/32.jpg)
CSC 205 Software Engineering I
32
Structure Chart Templates
COORDINATETRANSFORM
AFFERENT EFFERENT
X
X
A B
Z
Z
D D
![Page 33: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/33.jpg)
CSC 205 Software Engineering I
33
Overview - Object-Oriented Analysis and Design
• Introduction to OOAD• Introduction to Objects
– Background– Object-Oriented Programming– Classes and Objects– Object-Oriented Concepts
• Object Modeling Technique– Object-Oriented Analysis – Object-Oriented Design
![Page 34: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/34.jpg)
CSC 205 Software Engineering I
34
Object-Oriented Approaches
• Object-Oriented Methodology– development approach used to build complex systems
using the concepts of object, class, polymorphism, and inheritance with a view towards reusability
– encourages software engineers to think of the problem in terms of the application domain early and apply a consistent approach throughout the entire life-cycle
• Object-Oriented Analysis and Design– analysis models the “real-world” requirements,
independent of the implementation environment– design applies object-oriented concepts to develop and
communicate the architecture and details of how to meet requirements
![Page 35: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/35.jpg)
CSC 205 Software Engineering I
35
General Advantages
• Understandable– maps the “real-world” objects more directly– manages complexity via abstraction and encapsulation
• Practical– successful in real applications– suitable to many, but not all, domains
• Productive– experience shows increased productivity over life-
cycle– encourages reuse of model, design, and code
• Stable– changes minimally perturb objects
![Page 36: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/36.jpg)
CSC 205 Software Engineering I
36
Advantages wrt “Principles”• Separation of concerns
– developers focus on common versus special properties of objects
• Modularity– specifically in terms of classification of objects
• Abstraction– allowing common versus special properties to be represented
separately
• Anticipation of change– new modules (objects) systematically specialize existing objects
• Generality– a general object may be specialized in several ways
• Incrementality– specific requirements (e.g. performance) may be addressed in
specializations
![Page 37: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/37.jpg)
CSC 205 Software Engineering I
37
Object-oriented versus ClassicalSW development
Object-orientedAnalysis
Object-orientedDesign
Object-orientedImplementation
Maintenance
Requirements Analysis
Design
Implementation& Integration
Maintenance
![Page 38: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/38.jpg)
CSC 205 Software Engineering I
38
Background - Objects
• Traditionally, programming has been“procedure-oriented”– Focus on process, algorithms, and tools– A system’s data has secondary importance
• Data and process considered separate– The data is external to a program; a program
reads it in, manipulates it, and then writes it out– Relationships between data types not considered
important¤ As a result, similarities were not leveraged leading to
duplication of code
![Page 39: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/39.jpg)
CSC 205 Software Engineering I
39
Background, continued
• Problems– Lack of data encapsulation
¤ changes to a data format typically required major rewrites
– Poor models¤ Real world entities not well represented in requirements,
design and implementation• If an assumption about an entity changes, multiple modules
may have to change in response (since logic about an entity may be spread across modules)
– Low reuse¤ Procedure-oriented modules are often difficult to reuse
outside of their original development context
![Page 40: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/40.jpg)
CSC 205 Software Engineering I
40
Object-Oriented Programming
• Objects combine both data and process– Increases the stature of data to be equivalent to
process
• Focus on real-world entities– Objects often represent real-world counterparts:
people, countries, calendars, cars, organizations, etc.
• Enables Categorization– Objects with high levels of abstraction can often be
specialized to more specific categories¤ For instance, car Honda Civic¤ or person athlete soccer player
![Page 41: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/41.jpg)
CSC 205 Software Engineering I
41
Object-Oriented Programming, continued
• Addresses “Procedure-Oriented” Problems– Data and Process encapsulation
¤ Encapuslates data and related algorithms behind a single interface; both can be evolved without affecting other objects or modules (as long as the interface is constant)
– Natural Models¤ Objects can be used to appropriately structure a design
or accurately create a set of requirements based on knowlede about the real-world counterpart
– Increased Reuse¤ Well-designed object is often independent of the original
development context
![Page 42: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/42.jpg)
CSC 205 Software Engineering I
42
Object name
state(attributes)
access to attributesMethod 1
Method 2
Method 3
Objects
• Data and operations are defined as a single unit
• Object :=– encapsulated state (attributes)– methods that exclusively control access to the
state
![Page 43: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/43.jpg)
CSC 205 Software Engineering I
43
Classes
• Each object is an instance of a class• A class serves as a blueprint
– It defines the attributes and methods for the class– Thus, each object of a class has exactly the same
interface and set of attributes¤ each object can have different values for its attributes
Professor
Name: stringDept: string
get_name() return string....
class Professor
(Professor) (Professor)
Jean RaoulFrench
Debra RichardsonICS
get_name()....
get_name()....
Object instances of Professor
![Page 44: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/44.jpg)
CSC 205 Software Engineering I
44
Object Model Notation: Introduction
Class Name
(Class Name)
InstanceVariable1InstanceVariable2: type
InstanceVariable1 = valueInstanceVariable2: type
Method1()Method2(arguments) return type
Method1()Method2(arguments) return type
Classes are represented as rectangles;
The class name is at the top, followed by attributes (instance variables) and methods (operations)
Depending on context some information can be hidden such as types or method arguments
Objects are represented as rounded rectangles;
The object’s name is its classname surrounded by parentheses
Instance variables can display the values that they have been assigned; pointer types will often point (not shown) to the object being referenced
![Page 45: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/45.jpg)
CSC 205 Software Engineering I
45
Object Communication
• Objects communicate via method invocation– This is known as message passing– Legal messages are defined by the object’s interface– This interface is the only legal way to access another
object’s state
(Rectangle)
get_width
get_height
calculate_area
widthheight
Object
![Page 46: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/46.jpg)
CSC 205 Software Engineering I
46
Objects: Terminology (partial review)
• Class– set of objects having the same methods and attributes– has a specification and an implementation– behavior is defined by the operations that can be
performed on objects belonging to the class
• Method– action that can be performed on any member of a class
• Encapsulation– packaging the specification and implementation of a class
so that the specification is visible and the implementation is hidden from clients
• Instantiation– the creation of a new object belonging to a class
![Page 47: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/47.jpg)
CSC 205 Software Engineering I
47
Objects: Terminology, continued
• Aggregation– Objects representing components are associated with
an object representing their assembly (e.g. consists-of)– A mechanism for structuring object models
Weathermapping system
Weatherstation
Mapdatabase
Weathermap
consists of
![Page 48: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/48.jpg)
CSC 205 Software Engineering I
48
Aggregation: example
consists of
consists of
Microcomputer
Monitor System box Mouse Keyboard
Chassis CPU RAM Fan
![Page 49: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/49.jpg)
CSC 205 Software Engineering I
49
Objects: Terminology, continued
• Generalization– Allows a class, called a supertype, to be formed by factoring out
the common state and methods of several classes, called subtypes (is-a)
– Specialization is the converse case
Course
title
Undergrad Course
length
Postgrad Course
level
is-a
Supertype
Subtypes
![Page 50: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/50.jpg)
CSC 205 Software Engineering I
50
Generalization: example
DogDog CatCat
AnimalAnimal
is-a
Enables the creation of lists whichcan consist of elements withdifferent types!
animalList: listOf(Animal)
animalList CatCat AnimalAnimal DogDog
![Page 51: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/51.jpg)
CSC 205 Software Engineering I
51
Aggregation/ Generalization: example
consists of
consists of
Microcomputer
Monitor System box
Mouse Keyboard
Chassis CPU RAM Fan
Input Device
is-a
Color Monitor B/W Monitor
is-a
SpecializationGeneralization
![Page 52: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/52.jpg)
CSC 205 Software Engineering I
52
Objects: Terminology, continued
• Inheritance– a subclass inherits methods and attributes from its superclass;
a subclass can also add additional operations and attributes;– e.g.: subclasses Undergrad Course and Postgrad Course
inherit the title attribute from the superclass Course
• Class hierarchy– generalization and inheritance are transitive across the
hierarchy– e.g. vehicle->automobile->4-door->Suburu Legacy; the legacy
inherits from 4-door, automobile, and vehicle
• Multiple Inheritance– subclass inherits operations and attributes from more than
one superclass (not a strict hierarchy)
![Page 53: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/53.jpg)
CSC 205 Software Engineering I
53
Class Hierarchy - Single Inheritance: example
is-a
is-a
is-ais-a
Vehicle
LandVehicle WaterVehicle AirVehicle
truckcar
sailboat
airplane helicopter
motorboat ship yatch
![Page 54: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/54.jpg)
CSC 205 Software Engineering I
54
Class Hierarchy - Multiple Inheritance: example
is-a
is-a
Vehicle
is-a
LandVehicle WaterVehicle
Car AmphibiousVehicle
Boat
![Page 55: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/55.jpg)
CSC 205 Software Engineering I
55
Polymorphism
• A superclass defines an operation which its subclasses override.
• Via generalization a client may have a variable of the superclass type which is pointing to an instance of the subclass.
• When the operation is called, the subclass’s implementation is invoked
![Page 56: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/56.jpg)
CSC 205 Software Engineering I
56
Polymorphism: example
is-a
is-a
Vehicle
is-a
LandVehicle WaterVehicle
Car AmphibiousVehicle
Boat
defines methodsturnOn() andturnOff()
Each subclass implements turnOn() and turnOff()
![Page 57: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/57.jpg)
CSC 205 Software Engineering I
57
Polymorphism: example, continued
myVehicle: Vehicle := new Boat();
myVehicle->turnOn();
myVehicle->turnOff();
• In both cases, its Boat.turnOn() and Boat.turnOff() that’s executed!
![Page 58: CSC 205 Software Engineering I 1 Overview - Design Introduction to Design Review of Architectural Design Modules Structured Design Objects Object-Oriented](https://reader030.vdocuments.us/reader030/viewer/2022032521/56649d605503460f94a407c1/html5/thumbnails/58.jpg)
CSC 205 Software Engineering I
58
Good and poor object classesDiscussion• Reasonableness of an object depends on the
problem at hand: the challenge of O-O analysis is to find relevant object classes
¤ Country: USA, Australia¤ State: California, Washington¤ Thermometer¤ Temperature: 32°F¤ Computer file¤ Swimming¤ Students¤ Class of students¤ Students whose middle initial is J¤ Inventory¤ Automobile Part¤ Part ID