Object-orient design and
functional models
Software Design Notations
Functional vs. Object Oriented
Two fundamental approaches to software design
Functional
Object-Oriented
Functional (a.k.a “Structured”) the high level functionality can be repeatedly
broken down into smaller and smaller functions in order to reduce complexity.
Object-Oriented takes the approach that functionality belongs with “objects”,
which are software elements that have identity and whose state and behavior
is self-contained.
Software Design Notations
Five Aspects of Structured Design
1. Form of the problem guides the form of the solution
2. Reduces complexity by organizing the system into a hierarchy of
“black boxes”
3. Uses graphical tools to render systems readily understandable
4. Provides solution strategies based on a well-defined problem
statement
5. Provides criteria for evaluating the quality of the design
Software Design Notations
Four goals of Structured Design
1. Each black box should solve well-defined piece of the problem
2. The system should be partitioned so that the function of each
black box is easy to understand
3. Partitioning should be done so that any connection between black
boxes is introduces only because of a connection between pieces
of the problem
Software Design Notations
Key Structured Diagrams
Like any approach to software design, a structured approach
prescribes certain diagrams:
Data Flow Diagram
Shows the partitioning of the system into processes, data
sources, data sinks, and data stores
Shows how data flows between these elements
Structure Chart
Shows the partitioning of a system into modules (black boxes)
Shows how modules communicate with each other
Software Design Notations
Data Flow Diagram Example
Data Source/Sink Process
Data Flow
Data Store
Example
Software Design Notations
Structure Chart Example
Module
Data
Call
Example
Software Design Notations
Object-Oriented Design
Object-oriented is a proven approach to the analysis and design
of large, complex computer systems
Focuses on objects, their state and behavior
As opposed to a functional decomposition approach
CASE tools, 4th Generation Languages (4GLs), and design
languages supplement object-orientation, examples:
Powerbuilder
Visual Basic
Unified Modeling Language
Object models
Structure the system into a set of loosely coupled objects with
well-defined interfaces
Object-oriented decomposition is concerned with identifying object
classes, their attributes and operations
When implemented, objects are created from these classes and
some control model used to coordinate object operations
Object model
Data/class design transforms class models into design class
realizations and data structures required to implement the
software.
The objects and relationships defined in the class diagram are
the basis for the data design
Design class model
A design class is an abstraction of an implementation class.
Operations, attributes, types, visibility (public, protected, private
...), etc. can be specified with the syntax of the chosen language.
Relationships between design classes are translated directly into
the language:
generalization: inheritance
associations, aggregations: attributes
Design class
Interface class: Define abstractions for human-computer interaction.
Domain class: classes that implement some element of the domain (wood,
congress, book, course). Gather the necessary attributes and methods.
Process class: Implement business abstractions, required to manage
domain classes (make a sale, register an attendee, make a loan).
Persistent class: Represent data storage (database) that will persist beyond
the software execution.
System class: Implement the management and control functions of the
software, allow the communication and operation of the system with its
environment.
Design class
A design class must be “well-formed” and it must meet 4 characteristics:
Complete and sufficient: The class must be the encapsulation of all
attributes and methods reasonably associated with what the class
represents.
Primitivism: The methods must be exclusive services for the class (avoid
dependency).
High cohesion: Small and focused set of responsibilities.
Low coupling: Collaboration between classes to the minimum acceptable.
Communication only with neighboring classes .
High coupling makes the system difficult to implement, test and maintain.
Steps in design model using classes
1. Identify the design classes from the corresponding
analysis classes involved in the use case.
Steps in design model using class model
2. Identify responsibilities of design classes (from analysis classes).
Identify:
Operations
Attributes
Relationships in which it participates
methods that support its operations
Example: Realization of use case: place order
online
Steps in design model using class model
3. Describe interactions between design objects: sequence
diagrams, normal and alternate course(s)
Class diagram relationship type
Classes are
interrelated to each
other in specific
ways.
Association
• A relationship between two classes
that describes how they
communicate.
• A simple line connects the classes
• An arrow can be used to model a
directed association
• Each association can have a name
that describes the relationship
Generalization or inheritance
• An "is-a" relationship between
classes
• One class inherits the properties
and behaviors of another class
• A solid line with a closed, hollow
arrowhead pointing from the / La clase padre Persona
subclass to the superclass class Persona {
void getEdad() {
System.out.println(“La edad es:");
}…
}
// La clase Estudiante hereda de la clase Persona
class Estudiante extends Persona {
void getEdad() {
System.out.println(“El estudiante tiene");
}…
Dependency
• Class A uses class B, but neither
class A nor class B strictly owns
each other
• For example, a car depends on
an engine to drive
Agregation
• A class is part of or subordinate to
another class
• For example, a library is made up
of one or more books
Composition
• A stronger form of aggregation
where the aggregate controls the
lifecycle of the elements it
aggregates
• A filled diamond shape on the
containing class end of the line