0% found this document useful (0 votes)
28 views27 pages

Modelos de Mejora y Evaluación de Procesos - V3

The document outlines two primary software design approaches: Functional and Object-Oriented. Functional design focuses on breaking down functionality into smaller functions, while Object-Oriented design emphasizes objects that encapsulate state and behavior. It also discusses structured design principles, goals, and key diagrams such as Data Flow Diagrams and Structure Charts, alongside the characteristics and relationships of design classes in Object-Oriented design.

Uploaded by

julian :v
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views27 pages

Modelos de Mejora y Evaluación de Procesos - V3

The document outlines two primary software design approaches: Functional and Object-Oriented. Functional design focuses on breaking down functionality into smaller functions, while Object-Oriented design emphasizes objects that encapsulate state and behavior. It also discusses structured design principles, goals, and key diagrams such as Data Flow Diagrams and Structure Charts, alongside the characteristics and relationships of design classes in Object-Oriented design.

Uploaded by

julian :v
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

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

You might also like