Automation System Boundary

Pranz Wally G.
Merillo
20-1464
BAIT-2B
December 5, 2021
1. Automation System Boundary
System System boundary is the separation between a system and its

environment that inputs and outputs must cross whereas Automation
boundary is the separation between the automated part of a system and
the manual part of a system.
2. Structure Chart represents the hierarchical structure of modules. It

represents the software architecture that means the various modules
making up the system and the dependency. Structure chart
representation can be easily implemented using some common
programming language. The main focus in the structure chart is on
the module structure of the software.
Flowchart is a graphical representation of an algorithm.

Programmers often use it as a program-planning tool to solve a
problem. It makes use of symbols which are connected among them
to indicate the flow of information and processing. Flow chart is a
convenient technique to represent the flow of control in a program.
3. Developing a structure chart

4. Steps to create structure chart from DFD Fragment.
 Break the system into suitably tractable units by means of transaction

analysis
 Convert each unit into into a good structure chart by means of
transform analysis
 Link back the separate units into overall system implementation
5. Steps to create a structure art from a DFD fragment
structure chart describes overall organization of system program in

graphical representation. It has sequence of all components need to be
included in a program at high level (implementation). The qualities of a good
structure chart are as given below: High Fan-In value. Control couple flow low
to high. Data couple passed should be utilized by receiving module Each
module should perform only one function (high cohesion). Module sparingly
shares information (loose coupling). Library module need to be created
whenever required. Reasonable amount of code associated with each
module. Control module has no more than seven subordinate modules. The
ways to ensure quality of structure chart are as given below: High cohesion : It
ensures that line of code within each structure chart module is well related
with each other’s implying that module is efficient, understandable, easy to
implement. High fan-in: It ensures Reusability of a particular module and
occurrence of library module. It also make task for performing changes easy.
Loose coupling: It shows that level of interaction between modules is low
hence module can work independently and efficiently. Low fan-out: It shows
that less number of subordinate module related with a control module allow it
to work more effectively. 2. Program specification is a process of describing
each module on structure chart in a well defined written document that
includes instruction on how to program a piece of code. It is.
6. Module Algorithm Design Pseudocode
Pseudocode is one method of designing or planning a

program. Pseudo means false, thus pseudocode means false code. A better
translation would be the word fake or imitation. Pseudocode is fake (not the
real thing). It looks like (imitates) real code but it is NOT real code. It uses
English statements to describe what a program is to accomplish. It is fake
because no compiler exists that will translate the pseudocode to any machine
language. Pseudocode is used for documenting the program or module
design (also known as the algorithm).
7. Three layer design
Presentation tier
The presentation tier is the user interface and communication layer of the
application, where the end user interacts with the application. Its main
purpose is to display information to and collect information from the user. This
top-level tier can run on a web browser, as desktop application, or a graphical
user interface (GUI), for example. Web presentation tiers are usually
developed using HTML, CSS and JavaScript. Desktop applications can be
written in a variety of languages depending on the platform.
Application tier
The application tier, also known as the logic tier or middle tier, is the heart of
the application. In this tier, information collected in the presentation tier is
processed - sometimes against other information in the data tier - using
business logic, a specific set of business rules. The application tier can also
add, delete or modify data in the data tier.
The application tier is typically developed using Python, Java, Perl, PHP or
Ruby, and communicates with the data tier using API calls.
Data tier
The data tier, sometimes called database tier, data access tier or back-end, is
where the information processed by the application is stored and managed.
This can be a relational database management system such as PostgreSQL,
MySQL, MariaDB, Oracle, DB2, Informix or Microsoft SQL Server, or in
a NoSQL Database server such as Cassandra, CouchDB or MongoDB.
In a three-tier application, all communication goes through the application tier.

The presentation tier and the data tier cannot communicate directly with one
another.
8. Purpose and Objectives of Object oriented design
The main aim of Object Oriented Design (OOD) is to improve the
quality and productivity of system analysis and design by making it more
usable. In analysis phase, OO models are used to fill the gap between
problem and solution. ... It facilitates changes in the system at low cost. It
promotes the reuse of components.
9. Types of software system
 Operating system: Harnesses communication between hardware, system

programs, and other applications.
 Device driver: Enables device communication with the OS and other
programs.
 Firmware: Enables device control and identification.
 Translator: Translates high-level languages to low-level machine codes.
 Utility: Ensures optimum functionality of devices and applications.
10. Components Diagram

Component diagrams are essentially class diagrams that focus on a system's
components that often used to model the static implementation view of a system.
Sequential Diagram
Sequence Diagram is an interaction diagram that details how operations are carried out
-- what messages are sent and when.
Deployment Diagram
A deployment diagram is a UML diagram type that shows the execution
architecture of a system, including nodes such as hardware or software
execution environments, and the middleware connecting them.
11. Layer of Architectural Design
 The presentation layer : It contains all categories related to the

presentation layer.
 The business layer : It contains business logic.

 The persistence layer : It’s used for handling functions like object-
relational mapping
 The database layer : This is where all the data is stored.
12. Object-oriented design is the process of planning a system of interacting
objects for the purpose of solving a software problem.
13. Design class and notation
14. Detailed design with CRC cards
A Class Responsibility Collaborator (CRC) model (Beck & Cunningham 1989;

Wilkinson 1995; Ambler 1995) is a collection of standard index cards that
have been divided into three sections, as depicted in Figure 1. A class
represents a collection of similar objects, a responsibility is something that a
class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities. Figure 2 presents an example of two hand-
drawn CRC cards.
Figure 1: CRC card layout

Figure 2: Hand drawn CRC Cards
14. Fundamental detailed Design Principles
Single Responsibility Principle (SRP)
The SRP requires that a class should have only a single responsibility.
Example: If a class SalesOrder keeps information about a sales order, and in

addition has a method saveOrder() that saves the SaleOrder in a database
and a method exportXML() that exports the SalesOrder in XML format, this
design will violate the SRP because there will be different types of users of
this class and different reasons for making changes to this class. A change
made for one type of user, say change the type of database, may require the
re-test, recompilation, and re-linking of the class for the other type of users.
A better design will be to have the SalesOrder class only keeps the

information about a sales order, and have different classes to save order and
to export order, respectively. Such a design will confirm to SRP.
Open-Closed Principle (OCP)
The OCP requires that each software entity should be open for extension,
but closed for modification.
Example: Suppose an OrderValidation class has a method validate(Order

order) that is programmed to validate an order based on a set of hard-coded
rules. This design violates the OCP because if the rules change,
the OrderValidation class has to be modified, tested, and compiled.
A better design will be to let the OrderValidation class contain a collection

of ValidationRule objects each of which has a validate(Order order) method
(perhaps defined in a Validation interface) to validate an Order using a
specific rule, and the validate(Order order) method of OrderValidation class
can simply iterate through those ValidationRule objects to validate the
order. The new design will satisfy the OCP, because if the rules change, we
can just create a new ValidationRule object and add it to
an OrderValidation instance at run time (rather than to the class definition
itself).
This is can also be achieved by using subclasses of a base

class AbstractValidationRule that has an override-able
function validate(Order order). Subclasses can implement the method
differently without changing the base class functionality.

Automation System Boundary

Uploaded by

Copyright:

Available Formats

Automation System Boundary

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automation System Boundary

Uploaded by

Copyright:

Available Formats

Pranz Wally G.

1. Automation System Boundary

System System boundary is the separation between a system and its

2. Structure Chart represents the hierarchical structure of modules. It

Flowchart is a graphical representation of an algorithm.

3. Developing a structure chart

 Break the system into suitably tractable units by means of transaction

5. Steps to create a structure art from a DFD fragment

structure chart describes overall organization of system program in

6. Module Algorithm Design Pseudocode

Pseudocode is one method of designing or planning a

7. Three layer design

In a three-tier application, all communication goes through the application tier.

8. Purpose and Objectives of Object oriented design

9. Types of software system

 Operating system: Harnesses communication between hardware, system

10. Components Diagram

11. Layer of Architectural Design

 The presentation layer : It contains all categories related to the

 The business layer : It contains business logic.

A Class Responsibility Collaborator (CRC) model (Beck & Cunningham 1989;

Figure 1: CRC card layout

Single Responsibility Principle (SRP)

Example: If a class SalesOrder keeps information about a sales order, and in

A better design will be to have the SalesOrder class only keeps the

Open-Closed Principle (OCP)

Example: Suppose an OrderValidation class has a method validate(Order

A better design will be to let the OrderValidation class contain a collection

This is can also be achieved by using subclasses of a base

You might also like