ASE-9316 Lecture UP 3

Factory Automation and
Industrial Informatics
ASE-9316 Introduction to Industrial Informatics
* 1
Unified Process (cont.)
Project costs calculation
Use cases and Domain Classes
Project Libre and Costs validation
* 1
Figure 3-18
MS Project Showing Project Labor Costs
5 Object-Oriented Analysis and Design
with the Unified Process
Figure 3-22
Net Present Value, Payback Period, and Return on Investment for RMO
Completing the Inception Phase
• Inception activities are project foundation
• Summary of key deliverables of inception
– Project charter package
– Essential use case list
– Project schedule
– Cost/benefit analysis
– Project feasibility and risk analysis
• General scope and approach should be clearly
defined
• Scope and essential use case lead to elaboration
phase
Objectives
¥Explain how events can be used to identify use cases
that define requirements
¥Identify and analyze events and resulting use cases
¥Explain how the concept of problem domain classes

also defines requirements
¥Identify and analyze domain classes needed in the

system
Object-Oriented Analysis and Design with the Unified Process 9

Objectives (continued)
¥Read, interpret, and create a Unified Modeling
Language (UML) domain model class diagram and
design class diagram
¥Use a CRUD matrix to study the relationships

between use cases and problem domain classes

Overview
¥Objective: refine information gathered
¥Identify use cases and problem domain classes
¥Model problem domain classes with UML notation
¥Introduce use case modeling

Events and Use Cases
¥Use case
¤Activity the system carries out
¤Entry point into the modeling process
¥Event decomposition: help identify use cases
¥Elementary business processes (EBPs)
¤Basic unit of analysis
¤Initiated by event occurring at specific time and place
¤Discrete system response that adds business value
Figure 5-1
Identifying Use Cases by Focusing on Users and their Goals

Event Decomposition
¥Event decomposition
¤Develops use cases based on system response to events
¤Perceives system as black box interfacing with
external environment
¤Keeps focus on EBPs and business requirements
¥Analysts delegated particular events to decompose
¥Result of the decomposition:
¤List of use cases triggered by business events
¤Use cases at the right level of analysis
Figure 5-2
Events Affecting a Charge Account Processing System that Lead to Use Cases

Types of Events
¥External Events
¤Occur outside the system
¤Usually caused by external agent
¥Temporal Events
¤Occurs when system reaches a point (deadline) in time
¥State Events
¤Asynchronous events responding to system trigger
Figure 5-3
External Event Checklist

Figure 5-4
Temporal Event Checklist

Identifying Events
¥Three rules of thumb
¥Distinguish events from prior conditions

¤Can the transaction complete without interruption?
¤Is the system waiting for next transaction?
¥Trace sequence of events initiated by external agent

¤Isolate events that actually touch the system

Figure 5-5
Temporal Event Checklist

Figure 5-6
The Sequence of “Transactions” for One Specific Customer
Resulting in Many Events
Identifying Events (continued)
¥Identify technology dependent events
¤Example: logon depending on system controls
¥Defer specifying technology dependent events
¥Perfect technology assumption:
¤Separates technology dependent events from
functional requirements
◘ Unlimited processing and storage capacity
◘ Equipment does not malfunction
◘ Users have ideal skill sets
Figure 5-7
Events Deferred until Later Iterations

Events in the Rocky Mountain
Outfitters Case
¥Developing list of external events
¤Identify all people and organizational units that

want something from the system
¥Developing list of temporal events
¤Identify regular reports and statements that system

must produce at certain times

Figure 5-8
External Events for the RMO Customer Support System

Figure 5-9
Temporal Events for the RMO Customer Support System

Looking At Each Event and the
Resulting Use Case
¥Enter use cases in an event table
¥Event table includes rows and columns
¤Each row is a record linking an event to a use case
¤Columns represent key information
¥RMO event table anatomizes customer support

system

Figure 5-10
Information about each Event and the Resulting Use Case in an Event Table
Figure 5-11
The Complete Event Table for the RMO Customer Support System
Problem Domain Classes
¥Problem domain
¤Set of work-related “things” in system component
◘ Things have data representation within system
¤Examples: products, orders, invoices, customers
¥OO approach to things in problem domain
¤Objects that interact in the system
¥Identify and understand things in problem domain
¤Key initial steps in defining requirements

Types of Things
¥Things can be identified with methodology
¥Separate the tangible from the intangible
¥Include information from all types of users
¥Ask important questions about nature of event
¤“What actions upon things should be
acknowledged and recorded by the system?”
¥Example case: customer placing an order

Figure 5-12
Types of Things
Procedure for Developing an
Initial List of Things
¥List nouns users mention when discussing system
¥Event table as source of potential things
¤Use cases, external agents, triggers, response
¥Select nouns with questions concerning relevance
¤Further research may be needed

Figure 5-13a
Partial List of “Things” Based on Nouns for RMO
Figure 5-13b
Figure 5-13c
Associations among Things
¥Analyst document entity associations ( relationships)
¤Example: “Is placed by” and “works in”
¥Associations apply in two directions
¤Customer places an order
¤An order is placed by a customer
¥Multiplicity: the number of associations
¤One to one or one to many
¥The associations between types of things
¤Unary (recursive), binary, n-ary
Figure 5-14
Associations Naturally Occur between Things

Figure 5-15
Multiplicity of Relationships

Attributes of Things
¥Specific details of things are called attributes
¥Analyst should identify attributes of things
¥Identifier (key): attribute uniquely identifying thing

¤Examples: Social Security number, vehicle ID
number, or product ID number
¥Compound attribute is a set of related attributes

¤Example: multiple names for the same customer
Figure 5-16
Attributes and Values

Classes and Objects
¥Domain model class diagram as UML class
¤OOA applies domain model class diagram to things
¥Problem domain objects have attributes
¥Software objects encapsulate attributes and
behaviors
¤Behavior: action that the object processes itself
¥Software objects communicate with messages
¥Information system is a set of interacting objects
Figure 5-17
Objects Encapsulate Attributes and Methods

Domain Model Class Diagram
Notation
¥Class diagram key
¤General class symbol: rectangle with three
sections
¤Sections convey name, attributes, and behaviors
¤Methods (behaviors) not shown in domain model
class diagram
¤Lines connecting rectangles show associations
¤Multiplicity reflected above connecting lines
¥Domain class objects reflect business concern,
policies, and constraints
Figure 5-21
An Expanded Domain Model Class Diagram Showing Attributes

Figure 5-24
A Refined University Course Enrollment Domain Model Class
Diagram With an Association Class
Hierarchies in Class Diagram
Notation
¥Generalization/specialization notation
¤ Inheritance hierarchy
¤Rank things the more general to the more special
◘ Motor vehicle class includes trucks, cars, buses
¥Classification: means of defining classes of things

¤Superclass: generalization of a class
¤Subclass: specialization of a class

Figure 5-25
A Generalization/Specialization Hierarchy Notation for Motor Vehicles

Notation (continued)
¥Whole-part Hierarchy Notation
¤“The whole is equal to the sum of the parts”
¥Two types of whole-part hierarchies
¤Aggregation: association with independent parts
◘ Example: keyboard is part of computer system
¤Composition: association with dependent part
◘ Example: CRT and monitor
¥Multiplicity applies to whole-part relationships

Figure 5-27
Whole-part (Aggregation) Associations Between a Computer and Its Parts
Notation (continued)
¥Design Class Diagrams
¤Models classes into precise software analogs
¤Includes domain class information plus methods
¤Triangle symbol between classes indicates inheritance
¤Properties of attributes are shown with curly braces
¥Class fundamentals
¤Instances of a class (objects) manage their own data
¤Abstract classes are not instantiated (created)
¤Subclasses inherit attributes/behaviors from superclass
Figure 5-29
University Course Enrollment Design Class Diagram (With Methods)
The Rocky Mountain
Outfitters Domain Class
Diagram
¥Derives from noun list developed in Figure 5-13
¥RMO domain class diagram shows attribute
¥Models do not show methods
¥Problem domain classes reflect high-level view of

RMO use cases
Figure 5-31
Rocky Mountain Outfitters Domain Model Class Diagram
Locations and the Crud Matrix
¥Location diagrams store data for future reference
¤Shows need for network connections
¤Creates awareness of geographic reach
¥Use case–location matrix: shows where use cases
are performed
¥Use case–domain class matrix: highlights access
requirements
¤Example: The RMO CRUD (create, read, update,
and delete)
Figure 5-32
Rocky Mountain Outfitters Location Diagram
Figure 5-33a
Use Case–location Matrix for the Rocky Mountain Outfitters
Customer Support System
Figure 5-33b
Use Case–location Matrix for the Rocky Mountain Outfitters
Customer Support System
Use Cases, the Domain Model,
and Iteration Planning
¥Select use cases for further development
¤Identify risks to determine priority
¤Core architecture typically selected/implemented first
¥Transition into elaboration phase
¤Converting use cases into software
¤Iteratively integrate software components into more
complex systems
¤Begin testing of software
Summary
¥ Requirements discipline defines business functions
¥ Key concepts: use cases and problem domain classes
¥ Use cases derive from elementary business processes

(EBPs)
¥ Three event types: external, temporal, and state
¥ Problem domain class: category based on OOA

Summary (continued)
¥ Multiple associations among classes
¥ Attributes: specific information about a thing
¥ Actual software classes include behaviors (methods) and
attributes
¥ UML class diagrams show classes, attributes, methods,
and associations
¥ Domain model class diagram show domain classes in the
users’ work environment

Summary (continued)
¥Design class diagram models software classes
¥Generalization/specialization hierarchies allow

inheritance from a superclass to a subclass
¥Whole-part hierarchies allow a collection of objects

to be associated as a whole and its parts
¥Requirements are also defined with location

diagrams, and matrices

Objectives
¥Detailed Object-Oriented Requirements Definitions
¥System Processes—A Use Case/Scenario View
¥Identifying Inputs and Outputs—The System
Sequence Diagram
¥Identifying Object Behavior—The Statechart
Diagram
¥Integrating Object-Oriented Models

Overview
¥Refine requirements to threshold of implementation
¥Apply OOA to use cases and models
¥Translate process descriptions into working algorithms
¥Observe that analysis-design boundary is fluid

Detailed Object-Oriented
Requirements Definitions
¥System requirements captured with OO models
¥“Divide and conquer” strategy toward complexity
¥Two subsets of OO modeling approach
¤Use case driven extending four specific models
◘ Use case diagrams, use case descriptions, activity
diagrams, system sequence diagrams
¤Object driven extending statechart diagram

Figure 6-1
Requirements Diagrams With UML Models

Detailed Object-Oriented
Requirements Definitions
(continued)
¥Use case diagram: table of contents for business events
¥System sequence diagrams (SSDs)
¤Define and order sequence of inputs and outputs
¤Information flows referred to as messages
¥Class diagrams
¤Identify real-world “things”
¤Determine the structure of the programming classes
¥Statechart diagram describes collection of object states
System Processes—A Use
Case/Scenario View
¥Define use cases into two tiers:
¤Overview level derived from:
◘ Event table and use case diagrams
¤Detailed level derived from combination of:
◘ Use case description
◘ Activity diagram
◘ Sequence diagram

Use Cases and Actors
¥Source
¤Person or thing initiating the business event
¤Must be external to the system
¥Actor
¤Person or thing that touches the system
¤Lies outside of automation boundary
¥Identifying actors at the right level of detail
¤Assume actors (even non-human types) have hands
¤Use case is a goal that the actor wants to achieve

The Use Case Diagram
¥Notation for use case diagrams
¤Simple stick figure represents an actor
¤Actor’s hands indicate direct system access
¤Use case itself symbolized by an oval
¤Connecting lines match actors to use cases
¥Actors may also be other system interfaces
¤May be represented with stick figure or rectangle

Figure 6-2
A Simple Use Case with an Actor

Automation Boundary and
Organization
¥Expand use case diagrams with other actors and use
cases
¥Relationship line: allows each actor to interact with
each use case
¥Automation boundary
¤Line drawn around the entire set of use cases
¤Defines interface between actors and computer system

Figure 6-3
A Use Case Diagram of the Order-Entry Subsystem for
RMO, Showing a System Boundary
Figure 6-4
A Use Case Diagram of the Customer Support System (by
Subsystem)
« Includes » Relationships
¥«includes» or «uses» relationship
¤Use case calling services of common subroutine
¤Common subroutine itself becomes additional use case
¥Examples: “Validate customer account” and “Look
Up Item Availability”
¥Notation
¤Relationship denoted by connecting line with arrow
¤Direction of the arrow indicates major/minor cases
Figure 6-6
An Example of the Order-entry Subsystem With «Includes» Use
Cases
Developing a Use Case
Diagram
¥Two ways to identify additional use cases
¤Divide one large use case into two
¤Define another use case based on a common subroutine
¥Distinguish between temporal and state events
¥Iterative process translates business events to use cases
¤[1] Identify the actors and roles for each use case
¤[2] Extract system response to business events
¥Data of system stabilizes after completion of the goal
Use Case Detailed Descriptions
¥Use cases have internal complexity
¤Sequence of steps to execute business process
¤Several variations may exist within single use case
◘ Valid variation known as scenario
¤Example: “Create new order” varies from phone to

Internet order
¥Work with variety of diagrams and descriptions
for each use case
(continued)
¥Use case descriptions written at (3) levels of detail
¤Brief description
◘ Summary statement conjoined to activity diagram
¤Intermediate description
◘ Expands brief description with internal flow of activities
¤Fully Developed Description
◘ Expands intermediate description for richer view

Figure 6-7
Brief Description of Create New Order Use Case

Figure 6-8
Intermediate Description of Telephone Order Scenario for
Create New Order Use Case
(continued)
¥Fully developed use case description
¤Superset of intermediate and brief descriptions
¤Consists of eleven compartments
¤User, actor, stakeholder, EBP, and conditions
identified
¥Activity Diagram Description
¤Document the workflows of business processes
¤Document flow of activities for use case scenarios
¤Form basis of system sequence diagrams (SSDs)
Figure 6-10
Fully Developed Description of Telephone Order Scenario
for Create New Order Use Case
Figure 6-12
Activity Diagram of the Telephone Order Scenario
Identifying Inputs and Outputs—
the System Sequence Diagram
¥System sequence diagram (SSD)
¤Describes flow of information
¤Identifies interaction between actors and system
¤Message oriented

SSD Notation
¥Actor “interacts” with the system via input/output
¥SSDs use object notation
¤Box (rectangle) refers to individual object
¤Name of the object underlined
¤Messages sent/received by objects, not classes
¥Lifeline
¤Extension of object or actor for duration of the SSD
¤Indicates sequence of the messages sent/received

Figure 6-14
Sample System Sequence Diagram
SSD Notation (continued)
¥Message syntax can take several forms
¤Depends on send/return direction
¥Message semantics: actions (like commands)

invoked on destination object
¥Complete message notation:*[true/false condition]

return-value := message-name (parameter-list)

Figure 6-15
Repeating Message (A) Detailed Notation (B) Alternate
Notation
Developing a System Sequence
Diagram
¥Begin with detailed description of use case
¤Fully developed form
¤Activity diagrams
¥(4) step process for turning activity diagram into SSD
¤[1] Identify the input messages
¤[2] Describe messages from external actor to system
¤[3] Identify/apply special conditions to input messages
¤[4] Identify and add the output return messages
Figure 6-16
A Simplified Diagram of the Telephone Order Scenario
Developing a System Sequence
Diagram (continued)
¥Names of messages reflect services performed
¥Important principle for identifying data parameters
¤Base the list on the class diagram
¤Attributes from the classes listed as parameters
¥Iteratively define input/output parameters around
workflows
¥Objective: discovery and understanding

Figure 6-17
An SSD of the Simplified Telephone Order Scenario for the Create
New Order Use Case
Identifying the Object
Behavior¾the Statechart
Diagram
¥A state in a statechart similar to status condition
¤Spans many business events
¤Developed for complex problem domain classes
¥Statechart diagram
¤Composed of ovals representing status of object
¤Arrows represent transitions
Figure 6-19
Simple Statechart for a Printer

Identifying the Object
Behavior¾the Statechart
Diagram (continued)
¥Guidelines to help identify states
¤Check naming convention for status conditions
¤Simple states reflect simple conditions such as “On”
¤Complex states labeled with gerunds or verb phrases
◘ Example: “Being shipped”
¤Active states usually not labeled with nouns
¤Describe only states of being of the object itself
¤Status conditions reported to management/customers
◘ Example: “Shipped”
Nested States And
Concurrency
¥Concurrency: condition of being in more than one
state at a time
¥Two modes of representation
¤Use synchronization bars and concurrent paths
¤Nest low-level states inside higher-level states
¥Higher-level states also called composite states
¤Complex structure of sets of states and transitions
¤Represent a higher level of abstraction
Figure 6-20
Sample Composite States for the Printer Object

Figure 6-21
Concurrent Paths for the Printer in the On State

Rules for Developing
Statecharts
¥[1] Select the classes that will require statecharts
¥[2] List all the status conditions for each group
¥[3] Specify transitions that cause object to leave

the identified state
¥[4] Sequence state-transition combinations in

correct order

Rules for Developing
Statecharts (continued)
¥[5] Identify concurrent paths.
¥[6] Look for additional transitions
¥[7] Expand each transition as appropriate
¥[8] Review and test each statechart

Developing RMO Statecharts
¥Review the domain class diagram
¥Select classes with status conditions that need to
be tracked
¥Candidates: Order, OrderItem, InventoryItem,
Shipment, Customer
¥Choose Order and OrderItem
¤Simplicity
¤Location in the class hierarchy

Developing The Order Item
State Chart
¥Identify possible status conditions of interest
¤“Ready to be shipped”
¤“On back order”
¤“Shipped”
¥Continue developing statechart according to eight rules

Figure 6-22
States and Exit Transitions for Orderitem

Figure 6-24
Final Statechart for Orderitem

Developing the Order State
Chart
¥States mirror the life cycle of an order
¥Application of rules leads to greater complexity
¤Concurrent states
¤New transitions
¥Benefits of developing a statechart for an object
¤Captures and clarifies business rules
¤Gain true understanding of system requirements

Figure 6-25
States and Exit Transitions for Order

Figure 6-27
Second-cut Statechart for
Order
Integrating Object-Oriented
Models
¥Primary (or source) models
¤Use case diagram
¤Problem domain class diagram
¥CRUD analysis validates model completeness
¥Construction of one model depends on another
¥Models capturing processes of new system
¤Use case diagram and models to lower left
¥Models capturing information about classes
¤Class diagrams and dependencies
Figure 6-28
Relationships among OO Requirements Models

Summary
¥OOA family of models documents users’ needs and
defines system requirements
¥Use case detailed models (descriptive or activity)
¥System sequence diagrams (SSDs)
¥Domain model class diagrams
¥Statechart diagrams

Summary (continued)
¥Use case: single system function responding to an
event
¥Actors: human users or system interfaces that initiate
system response
¥System function decomposed into workflows
¥SSDs, domain models, statecharts emulate routines
and object interaction
¥Software engineering terms signal transition into
design phase
UML diagrams (example)
* 1
Conveyor In 2
Conveyor Out
Robot
Machine
Conveyor In 1
115
System description
• Manufacturing system is composed of a conveyor system, a robot and a machine. The
conveyor system is composed of three conveyor segments: two input conveyors and
one output conveyor. The input conveyors are used to deliver the unprocessed parts to
the robot working area. The robot is used to input these parts to the machine. The
machine is capable of processing one part at the time. The ready-made product can be
unloaded from the machine to the output conveyor. The unload operation is performed
by the same robot.
• The input conveyors are of two types. First one supplies the workpieces (parts) from
the single direction, while the second one may deliver workpieces from both directions.
• The control system has been implemented for this manufacturing system. It can be
used to retrieve most important run-time parameters.
• The company owning the manufacturing system has hired you to implement a
monitoring system, which should deliver some important information to its users and
allow minor adjustments of the production process at run-time.
• Management of the company wants to know the latest information on the amount of
products that have been manufactured so far, while the control engineers should be
able to get the status of each piece of equipment in the system. Control engineers
should be able to stop and start any of the equipments, adjust operation times, and get
some of characteristics such as work status and idle time as well as the locations of the
workpieces.
116
System description
• Manufacturing system is composed of a conveyor system, a robot and a machine. The
conveyor system is composed of three conveyor segments: two input conveyors and
one output conveyor. The input conveyors are used to deliver the unprocessed parts to
the robot working area. The robot is used to input these parts to the machine. The
machine is capable of processing one part at the time. The ready-made product can be
unloaded from the machine to the output conveyor. The unload operation is performed
by the same robot.
• The input conveyors are of two types. First one supplies the workpieces (parts) from
the single direction, while the second one may deliver workpieces from both directions.
• The control system has been implemented for this manufacturing system. It can be
used to retrieve most important run-time parameters.
• The company owning the manufacturing system has hired you to implement a
monitoring system, which should deliver some important information to its users and
allow minor adjustments of the production process at run-time.
• Management of the company wants to know the latest information on the amount of
products that have been manufactured so far, while the control engineers should be
able to get the status of each piece of equipment in the system. Control engineers
should be able to stop and start any of the equipments, adjust operation times, and
get some of characteristics such as work status and idle time as well as the locations
of the workpieces.
117
Node.js
Calling the services and
getting response
https://nodejs.org/
http://www.w3schools.com/svg/
* 1

ASE-9316 Lecture UP 3

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ASE-9316 Lecture UP 3

Enviado por

Direitos autorais:

Formatos disponíveis

Factory Automation and

ASE-9316 Introduction to Industrial Informatics

¥Identify and analyze events and resulting use cases

¥Explain how the concept of problem domain classes

¥Identify and analyze domain classes needed in the

Object-Oriented Analysis and Design with the Unified Process 9

¥Use a CRUD matrix to study the relationships

Object-Oriented Analysis and Design with the Unified Process 10

¥Identify use cases and problem domain classes

¥Model problem domain classes with UML notation

¥Introduce use case modeling

Object-Oriented Analysis and Design with the Unified Process 11

Object-Oriented Analysis and Design with the Unified Process 13

Object-Oriented Analysis and Design with the Unified Process 15

Object-Oriented Analysis and Design with the Unified Process 17

Object-Oriented Analysis and Design with the Unified Process 18

¥Distinguish events from prior conditions

¤Is the system waiting for next transaction?

¥Trace sequence of events initiated by external agent

Object-Oriented Analysis and Design with the Unified Process 19

Object-Oriented Analysis and Design with the Unified Process 20

Object-Oriented Analysis and Design with the Unified Process 23

¤Identify all people and organizational units that

¥Developing list of temporal events

¤Identify regular reports and statements that system

Object-Oriented Analysis and Design with the Unified Process 24

Object-Oriented Analysis and Design with the Unified Process 25

Object-Oriented Analysis and Design with the Unified Process 26

¥RMO event table anatomizes customer support

Object-Oriented Analysis and Design with the Unified Process 27

Object-Oriented Analysis and Design with the Unified Process 30

¥Example case: customer placing an order

¥Event table as source of potential things

¤Use cases, external agents, triggers, response

¥Select nouns with questions concerning relevance

¤Further research may be needed

Object-Oriented Analysis and Design with the Unified Process 38

Object-Oriented Analysis and Design with the Unified Process 39

¥Analyst should identify attributes of things

¥Identifier (key): attribute uniquely identifying thing

¥Compound attribute is a set of related attributes

Object-Oriented Analysis and Design with the Unified Process 41

Object-Oriented Analysis and Design with the Unified Process 43

Object-Oriented Analysis and Design with the Unified Process 45

¥Classification: means of defining classes of things

Object-Oriented Analysis and Design with the Unified Process 47

Object-Oriented Analysis and Design with the Unified Process 48

Object-Oriented Analysis and Design with the Unified Process 49

¥RMO domain class diagram shows attribute

¥Models do not show methods

¥Problem domain classes reflect high-level view of

¥ Key concepts: use cases and problem domain classes

¥ Use cases derive from elementary business processes

¥ Three event types: external, temporal, and state

¥ Problem domain class: category based on OOA

Object-Oriented Analysis and Design with the Unified Process 60

Object-Oriented Analysis and Design with the Unified Process 61

¥Generalization/specialization hierarchies allow

¥Whole-part hierarchies allow a collection of objects

¥Requirements are also defined with location

Object-Oriented Analysis and Design with the Unified Process 62

Object-Oriented Analysis and Design with the Unified Process 64

¥Refine requirements to threshold of implementation

¥Apply OOA to use cases and models