Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture and Design Illuminated CH4 - Coggle Diagram
Software Architecture
and Design Illuminated CH4
Chapter 4:
Object-Oriented Paradigm
4.1 Overview
Introduction to Object- Oriented
OO Software Engineering
OO Analysis
OO Design
OO Programming
A very popular design approach, applies to
many of the software architecture styles.
Popular since 1980’s.
OO Programming language: C++, Java, C#
OO Principles
Polymorphism
Poly – multiple. Morph – form
Polymorphism : refer to ability of an object to behave differently and assume different
forms based on its inheritance hierarchy
Polymorphism includes:
Vertical override operations between parent classes and derived classes
Horizontal overloading operations within the same class.
Encapsulation
Often called information hiding
Purpose: separate interface from implementation. By hiding the implementation details that are likely to change -> allows for flexibility in design,
easy teamwork working.
Example:
-C++: header and cpp file are separated.
-Stack with push, pop operation, however its inside can be implement with array or linked list
Inheritance
A class can inherit from its base class
Inheritance allows , hence improving the effectiveness of
software development.
Trừu tượng
Use Of OO
OO Programming language: C++, Java, C#
Although treated as an "architecture style" in the book
All other architecture styles can be described using OO
4.2 Introducing the Object-Oriented
Paradigm
4.2.1 Classes and Objects
Class consists of
Public interface
Detailed implementation
Definition of class usually consists of
"name" of the class
Possibly included in a package or namespace
List of attributes
List of operations
Special operations: constructor, desttructor, etc.
4.2.2 Relationships
Generalization Relation
The generalization relationship is also known as the inheritance or "is a" relationship.
Subclass is considered to be a specialized form of super class. Super class is considered as 'Generalization' of subclass.
The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line
4.2.2.1 Composition
Composition is a stronger variant of the "owns a“ relationship
Composition is more specific than aggregation.
Requirement: the lifespan of “components” and “owner” involved in a composition relationship must be same.
Is represented using a solid diamond arrowhead
4.2.2.2 Aggregation
Aggregation is a special case of association.
A kind of “whole-part” relationship.
Parts do not have to share the same lifespan as owner.
In UML, aggregation is represented using a hollow diamond arrowhead
4.2.2.3 Association
An is a connection between classes, a semantic connection (link) between objects of the classes involved in the association.
An association is normally bidrectional
4.2.2.4 Inheritance
is represented using a line with a closed arrowhead.
If the line is dashed, it is a realization relationship
4.2.2.5 Composition vs. Inheritance
Use inheritance only if derived class IS-A base class
E.g., HouseOwner is a Person
Composition (Aggregation) is used to model
relationship
E.g., HouseOwner has a House
Careful about inheritance, sometimes, weakens the
encapsulation principle
4.3 00 Analysis
4.3.1 Step 1: Design of a UML Use Case Diagram
Use Case is a way that a user accesses the system
User can be either real human user, or components of a bigger picture
Use Case Diagram depicts their relationship
4.3.2 Step 2: Develop an Analysis Class Diagram
via Noun Extraction
Analysis Class Diagram
also called "Concepts Class Diagram"
Describes
Key classes of a system
Their relationship
Abstraction of the system
Not every class in analysis class diagram is
implemented
The diagram does not include all classes in the real
implementation
4.4 OO Design
4.4.1 Step 1: Identify Classes—CRC Card
4.4.2 Step 2: Construct an Interaction Diagram
4.4.3 Step 3: Build a State Machine Diagram
4.4.4 Step 4: Class Specification
4.5 Design Principles
4.5.1 Principle of Decoupling
4.5.2 Ensuring Cohesion
4.5.3 Open-Closed Principle