Software Engineering

System Engineering And System Modeling

Lecture 3, 4
Teacher : Dr Brekhna
 Information engineering
• It is a software engineering approach to
designing and developing information
systems.
• It can also be considered as the generation,
distribution, analysis and use of information in
system
 System Engineering Process
• The system engineering process begins with a world view; the
business or product domain is examined to ensure that the
proper business or technology context can be established
• The world view is refined to focus on a specific domain of
interest
• Within a specific domain, the need for targeted system
elements is analyzed
• Finally, the analysis, design, and construction of a targeted
system element are initiated
• At the world view level, a very broad context is established
• At the bottom level, detailed technical activities are conducted
by the relevant engineering discipline (e.g., software
engineering)
"Always design a thing by considering it in its next larger context –
a chair in a room, a room in a house, a house in an environment, 3
and environment in a city plan"
System Engineering Hierarchy
World
View

Domain
View

Element
View

Component
View

4
 System Modeling
(at each view level)
• Defines the processes (e.g., domain classes in OO terminology) that
serve the needs of the view under consideration
• Represents the behavior of the processes and the assumptions on
which the behavior is based
• Explicitly defines intra-level and inter-level input that form links
between entities in the model
• Represents all linkages (including output) that will enable the
engineer to better understand the view
• May result in models that call for one of the following
– Completely automated solution
– A semi-automated solution
– A non-automated (i.e., manual) approach

5
 Factors to Consider when
Constructing a Model
• Assumptions
– These reduce the number of possible variations, thus enabling a
model to reflect the problem in a reasonable manner
• Simplifications
– These enable the model to be created in a timely manner
• Limitations
– These help to bound the maximum and minimum values of the
system
• Constraints
– These guide the manner in which the model is created and the
approach taken when the model is implemented
• Preferences
– These indicate the preferred solution for all data, functions, and
behavior
– They are driven by customer requirements

Optimization of some of these factors may be mutually exclusive 6

 Business Process Engineering
• “Business process” engineering defines architectures that will
enable a business to use information effectively
• It involves the specification of the appropriate computing
architecture and the development of the software architecture
for the organization's computing resources
• Three different architectures must be analyzed and designed
within the context of business objectives and goals
– The data architecture provides a framework for the
information needs of a business (e.g., ERD)
– The application architecture encompasses those elements
of a system that transform objects within the data
architecture for some business purpose
– The technology infrastructure provides the foundation for
the data and application architectures
• It includes the hardware and software that are used to
support the applications and data
7
The BPE Hierarchy…
The enterprise Information strategy planning
(World view)

Business area

A business area Business area analysis

(Domain view)

Processing requirement

Informati Business system

on design
system (Element view)

Software
Engineering

Construction
&
Integration
(Detailed view)

8
 Information Strategy Planning
• Management issues
define strategic business goals/objectives
isolate critical success factors
conduct analysis of technology impact
perform analysis of strategic systems
• Technical issues
create a top-level data model
cluster by business/organizational area
refine model and clustering
9
Defining Objectives and Goals

• Objective—general statement of direction

• Goal—defines measurable objective: “reduce
manufactured cost of our product”
 Subgoals:
• decrease reject rate by 20% in first 6 months
• gain 10% price concessions from suppliers
• re-engineer 30% of components for ease of
manufacture during first year
• Objectives tend to be strategic while goals
tend to be planned

10
 Product Engineering
• Product engineering translates the customer's desire
for a set of defined capabilities into a working product
• It achieves this goal by establishing a product
architecture and a support infrastructure
– Product architecture components consist of people,
hardware, software, and data
– Support infrastructure includes the technology
required to tie the components together and the
information to support the components
• Requirements engineering elicits the requirements
from the customer and allocates function and
behavior to each of the four components
11
 Product Engineering...
• System component engineering happens next as a set of
concurrent activities that address each of the components
separately
– Each component takes a domain-specific view but
maintains communication with the other domains
– The actual activities of the engineering discipline takes
on an element view
• Analysis modeling allocates requirements into function,
data, and behavior
• Design modeling maps the analysis model into data/class,
architectural, interface, and component design
Product Engineering Hierarchy
Product Requirements
Engineering
System
Human Hardware Software Database Component
Engineering Engineering Engineering Engineering Engineering

Data and Analysis

Function Behavior
Classes Modeling

Data/Class Architectural Interface Component Design

Design Design Design Design Modeling

Construction

13
 System Modeling with UML
• The Uniform Modeling Language (UML) provides
diagrams for analysis and design at both the system
and software levels
• Examples
– Use case diagrams
– Activity diagrams
– Class diagrams
– State diagrams

14
 System Modeling with UML
• Deployment diagrams (Modeling hardware)
– Each 3-D box depicts a hardware element that is part of the
physical architecture of the system
• Activity diagrams (Modeling software)
– Represent procedural aspects of a system element
• Class diagrams (Modeling data)
– Represent system level elements in terms of the data that
describe the element and the operations that manipulate the
data
• Use-case diagrams (Modeling people)
– Illustrate the manner in which an actor interacts with the
system

15
Deployment Diagram
CLSS p ro ce s s or

So rt in g s u bs ys t e m Op e rat o r dis p lay

Se n s o r dat a
s h un t co nt rolle r
acqu is it io n s ub s ys t e m

Co nve yor Bar co d e re ad e r Sh un t act u at o r

Pu ls e t ach

16
Activity Diagram

Supplements the use-

case by providing a
diagrammatic
representation of
procedural flow
-Start is a single circle
-End is a bulls-eye
-Decisions are
diamonds
 Class Diagram
class nam e

Bo x
at t rib ut es
b arco de not e us e of c apit a l
fo rwardSpeed le t t er for mult i-word
co nveyo rLo cat io n at t ribut e na mes
heig ht
widt h
dept h
weig ht
co nt ent s
o perat io ns
(parent he s es at end
readBarco de ( ) of nam e indica t e t he
updat eSpeed ( ) lis t of at t ribut es t hat t he
readSpeed ( ) opera t ion require s )
updat eLo cat io n( )
readLo cat io n( )
g et Dim ensio ns( )
g et Weig ht( )
checkCo nt ent s( )
 Use-Case Diagram

Request bar code

Request shunt
control status

Request box
processing report

Update product
operator database

Run system
diagnostics

19
 Use Case

•Use cases specify desired behavior.

•A use case is a description of a set of
sequences of actions, including variants, a
system performs to yield an observable result
of value to an actor.
•Each sequence represent an interaction of
actors with the system.
 Specifying the Behavior of a Use Case

•Describing the flow of events within the use

case.
•Can be done in natural language, formal
language or pseudo-code.
•Includes: how and when the use case starts
and ends; when the use case interacts with
actors and what objects are exchanged; the
basic flow and alternative flows of the behavior.
 Actor
name

•An actor represents a set of roles that users

of use case play when interacting with these
use cases.
•Actors can be human or automated
systems.
•Actors are entities which require help from
the system to perform their task or are
needed to execute the system’s functions.
•Actors are not part of the system.
 Use Cases and Actors

•From the perspective of a given actor, a

use case does something that is of value to
the actor, such as calculate a result or
change the state of an object.
•The Actors define the environments in
which the system lives
Example of Use Case Diagram

registration

updating
grades
student faculty

output
generating
Relationships between Use Cases

•Generalization - use cases that are

specialized versions of other use cases.
•Include - use cases that are included as
parts of other use cases. Enable to factor
common behavior.
•Extend - use cases that extend the
behavior of other core use cases. Enable
to factor variants.
 parent
Generalization
•The child use case inherits the child

behavior and meaning of the

parent use case.
•The child may add to or override
the behavior of its parent.
Include base <<include>> included

•The base use case explicitly incorporates the behavior of

another use case at a location specified in the base.
•In UML modeling, a Include relationship is a relationship in
which one use case (base use case) contains the functionality
of another use case (inclusion use case). A containment
relationship supports the reuse of functionality in the use
case model.
Extend base <<extend>> extending

•The base use case implicitly incorporates the behavior of

another use case at certain points called extension points.
•The base use case may stand alone, but under certain
conditions its behavior may be extended by the behavior
of another use case
 Use Case Description
:Each use case may include all or part of the following
 Title or Reference Name - meaningful name of the UC
 Author/Date - the author and creation date
 Modification/Date - last modification and its date
 Purpose - specifies the goal to be achieved
 Overview - short description of the processes
 Cross References - requirements references
 Actors - agents participating
 Pre Conditions - must be true to allow execution
 Post Conditions - will be set when completes normally
 Normal flow of events - regular flow of activities
 Alternative flow of events - other flow of activities
 Exceptional flow of events - unusual situations
 Implementation issues - foreseen implementation problems

29
 Assignment 1
Choose an example yourself
• Make a use case diagram
• A class diagram
• Submission due:
Thank You 