Topic : Object Oriented Design Principles · 58 Object-Oriented Analysis and Design and the Unified Process Some Fundamental Design Principles •Encapsulation –Each object is a

Topic : Object Oriented Design Principles

Software EngineeringFaculty of Computing

Universiti Teknologi Malaysia

2Object-Oriented Analysis and Design with the Unified

Process

Objectives

• Describe the differences between requirements activities and design activities

• Explain the purpose of design and the difference between architectural and detailed design activities

• Describe 3 architectural styles

• Describe detailed design activities


Process

Comparison of Modeling During the Business Modeling, Requirements, and Design Disciplines

4

UML Diagrams


Process

Understanding the Elements of Design

• Systems design discipline

– Describe, organize, and structure system components

– Artifacts at architectural level and detailed level

– Purpose: enable system construction and deployment

• Two tiers of discipline tasks

– High (architectural)

• Hardware and system software infrastructure

– Low(detail design)

• Small modules such as software design for a use case


Process

Design Discipline Activities

• Segmented into 6 major activities– Design the support services architecture and

deployment environment (networking class)

– Design the software architecture focus of SE lecture

– Design use case realizations focus of SE lecture

– Design the database (database class)

– Design the system and user interfaces (HCI class)

– Design the system security and controls (network security; database security)


Process

Design the Software Architecture

• Software architecture refers to the “big picture”

• Two important aspects– Division of software into classes

– Distribution of classes across processing locations

• Modify class diagrams into software classes– Determine where classes and objects execute

– Determine whether they will be distributed

– Determine communication methods

– Select programming language(s) to write classes


Process

Design Use Case Realizations

• Use case realizations offer a lower-level view

• Two-tiered focus

– Class interactions supporting a particular use case

– Interactions among software, users, and external systems

• Design typically spread over many iterations

• UML design class diagrams and interaction diagrams document design

Design software architecture (high level design)

Client server architecture

Layered architecture

Repository architecture

9 Object-Oriented Analysis and Design with the Unified Process

Definitions

• Architectural design :

– The design process for identifying the sub-systems making up a system and the frameworkfor sub-system control and communication.

• The output of this design process is adescription of the software architecture.

2016 Software Engineering 10

Architectural Design

• An early stage of the system design process.

• Represents the link between specification anddesign processes.

• Often carried out in parallel with somespecification activities.

• It involves identifying major systemcomponents and their communications.


Architecture Analogy for Software vs. House?



Architecture Style

Client Server

Repository Layered


Process

Client/Server Architecture

• Client/server architecture tiers

– Client: requests resources or services from a server

– Server: manages information system resources

• Architectural issues for client/server software:

– Decomposing software into client and server programs (objects)

– Determining where clients and servers will execute

– Describing interconnection protocols and networks

Client-Server Architecture

• Distributed system model which shows how data andprocessing is distributed across a range ofcomponents.– Can be implemented on a single computer.– Set of stand-alone servers which provide specific

services such as printing, data management, etc.– Set of clients which call on these services.– Network which allows clients to access servers.

• Used when data in a shared database has to beaccessed from a range of locations.



Process

Client/Server Architecture with a Shared Database

Client/Server Architecture


Process

Client/Server Architecture(continued)

• Client and server communicate via well-defined protocols over a physical network

• Client/server architecture advantages

– Location flexibility, scalability, maintainability

• Client/server architecture disadvantages

– Additional complexity, potential poor performance, security issues, and reliability

Pros and Cons


Advantages Disadvantages

•Servers can be distributed across a network.

•Each service is a single point of failure so susceptible to denial of service attacks or server failure.

•General functionality (e.g. a printing service) can be available to all clients and does not need to be implemented by all services.

•Performance may be unpredictable because it depends on the network as well as the system.


Process

Interaction Among Multiple Clients and a Single Server

Repository Architecture

• Sub-systems must exchange data. This may bedone in two ways:– Shared data is held in a central database or repository

and may be accessed by all sub-systems;– Each sub-system maintains its own database and

passes data explicitly to other sub-systems.• When to use:

– large amounts of data are to be shared and stored fora long time.

– in data-driven systems where the inclusion of data inthe repository triggers an action or tool


Pros and Cons


Advantages Disadvantages

•Components can be independent.

•Changes made by one component can be propagated to all components.

• All data can be managed consistently (e.g. backups done at the same time)

•Problems in the repository affect the whole system.

•Inefficiencies in organizing all communication through the repository.

• Difficulties in distributing the repository across several computers

A Repository Architecture for an IDE



Process

Layered Architecture

• Variant of client/server architecture – Divides application software into independent

processes

• Three-layers – The data layer– The business logic layer– The view (presentation) layer

• Three-tier architecture advantages – Additional flexibility and reliability

Layered Model

• Used when:

– building new facilities on top of existing systems

– the development is spread across several teamswith each team responsibility for a layer offunctionality

– there is a requirement for multi-level security

– security is a critical requirement

• Example: Layered security architecture, a system toprovide file security


Pros and Cons

• Advantages:• Each layer can be considered to be an increasing level

of abstraction• Designers can use the layers to decompose a problem

into a sequence of more abstract steps• It’s easy to add or modify a layer as the need arises

• Disadvantages:• Not easy to structure a system in layers• The multiple layers of abstraction are not always

evident when examine a set of requirements• System performance may suffer from the extra

coordination among the layers



Process

Three-layer Architecture

A Client-Server Architecture for a Film Library


The Architecture of the LIBSYS System


COMPONENT DIAGRAMS AND ARCHITECTURAL DESIGN



Object oriented component notation


Extension notation for windows and web page


Two-Layer Architectural Design of Internet Systems


Three-Layer Architectural Design of Internet Systems

Principles of object oriented detailed design(low level design)

Design class diagram

Design class symbol

Fundamental detailed design principles


DESIGN CLASS DIAGRAM


Design class diagram


37 Object-Oriented Analysis and Design and the Unified Process

Java Program vs Class Diagram

DESIGN CLASS SYMBOL



Design Class Symbols

• Stereotypes

– UML notation to categorize a model element as a certain type

• Two types of notation

– Full notation with guillemets («»)

– Shorthand notation with circular icons

• Standard stereotypes

– Entity, control, boundary, data access


Standard stereotypes found in design models

Full notation

Shorthand notation


Reference from Center of Advanced Software Engineering (CASE)

Boundary Class

Example – Boundary Class



Entity Class



Example – Entity Class



Control class



Example control class




Design Class Notation

• Class name and stereotype information

• Attribute information– Visibility, type-expression, name, initial value, and

properties

• Method signature– Visibility, name, type-expression, and parameter

list

– Use the entire signature to identify a method to distinguish between overloaded methods


Internal Symbols and Example

Systems Analysis and Design in a Changing World, 6th Edition 49

Notation for Design Classesmethod arguments and return types not shown


Navigation Visibility

– The ability of one object to view and interact with another object

– Accomplished by adding an object reference variable to a class.

– Shown as an arrow head on the association line—customer can find and interact with sale because it has mySale reference variable


Navigation Visibility Guidelines

• One-to-many associations that indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate

• Mandatory associations, in which objects in one class can’t exist without objects of another class, are usually navigated from the more independent class to the dependent

• When an object needs information from another object, a navigation arrow might be required

• Navigation arrows may be bidirectional.


First Cut Design Class Diagram

• Proceed use case by use case, adding to the diagram

• Pick the domain classes that are involved in the use case (see preconditions and post conditions for ideas)

• Add a controller class to be in charge of the use case

• Determine the initial navigation visibility requirements using the guidelines and add to diagram

• Elaborate the attributes of each class with visibility and type

• Note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but they are often left on


Start with Domain

ClassDiagram

RMO Sales Subsystem


Create First Cut Design

ClassDiagram

Use Case Create phone sale with controller added


Developing the First-Cut Design Class Diagram

• Elaborate the attributes with type and initial value information– Most attributes should be private

• Add navigation visibility arrows– Based on which classes need access to which

other classes

– Can be bidirectional

– Will need to be updated as design progresses


Final DCD for the Process new order

use case

FUNDAMENTAL DETAILED DESIGN PRINCIPLES



Some Fundamental Design Principles

• Encapsulation– Each object is a self-contained unit containing

both data and program logic

• Object reuse– Standard objects can be used over and over

again within a system

• Information hiding– Data associated with an object is not visible

– Methods provide access to data


Some Fundamental Design Principles (continued)

• Navigation visibility– Describes which objects can interact with each other

• Coupling– Measures how closely classes are linked. – Objects which send messages to one another have navigation

visibility and thus are coupled.– Lower navigation visibility – lower coupling

• Cohesion– Measures the consistency of functions in a class– Cohesion is where the Classes perform one specific function– Classes which perform too much functions (low cohesion) hard to

be reused; difficult to understand and hard to maintain.• Separation of responsibilities

– Divides a class into several highly cohesive classes

EXTRA SLIDES ON COHESION AND COUPLING


Cohesion

61

Coupling

62

Cohesion and Coupling

63

Key Points

• A software architecture is a high level design todescribe of how a software system is organized.

• Architectural style are a means of reusing knowledgeabout generic system architectures. They describe thearchitecture, explain when it may be used and describeits advantages and disadvantages.

• Model involved in software architecture is componentdiagram.

• Object oriented detailed design is a low level designwhere the identification and description of sets ofobjects that must work together to carry put each usecase is done.

• Models involved in detailed design are class diagramand sequence diagram (will be elaborated in objectoriented design use case realizations lecture)


Key Points

• Models of application systems architectures help usunderstand and compare applications, validateapplication system designs and assess large-scalecomponents for reuse.

• Transaction processing systems are interactive systemsthat allow information in a database to be remotelyaccessed and modified by a number of users.

• Language processing systems are used to translatetexts from one language into another and to carry outthe instructions specified in the input language. Theyinclude a translator and an abstract machine thatexecutes the generated language.


Documents

Topic : Object Oriented Design Principles · 58 Object-Oriented Analysis and Design and the Unified Process Some Fundamental Design Principles •Encapsulation –Each object is a