Software Engineering
Natallia Kokash
email: nkokash@liacs.nl
N. Kokash, Software Engineering
1
Software Engineering

Modeling processes
 Rational
Unified Process (RUP)
 Model Driven Architecture (MDA)
 Software product lines
 Process modeling

Modeling techniques
 Entity-relationship
diagrams
 Finite state machines
 Data flow diagrams
 Class-responsibility-collaboration cards

N. Kokash, Software Engineering
Unified Modeling Language (UML)
2
Software Engineering
Rational Unified Process (RUP)




Iterative approach for object-oriented
systems
Strongly embraces use cases for
modeling requirements
Tool-supported (UML-tools,
ClearCase)
History
 Based
on Objectory process by
Jacobson
 Formalized by Kruchten (1998)
 Part of IBM Rational Method Composer
N. Kokash, Software Engineering
3
Software Engineering
RUP phases
Inception: establish scope,
boundaries, critical use cases,
candidate architectures, schedule
and cost
Elaboration: foundation of architecture,
establish tool support, get al use cases
Construction: manufacturing process, one or
more releases
Transition: release to user community, often
several releases




N. Kokash, Software Engineering
4
Software Engineering
Two-dimensional process
structure of RUP
N. Kokash, Software Engineering
5
Software Engineering
Inception

Construction
Transition
Prepare vision document and initial business
case
 Include

Elaboration
risk assessment and resource estimate
Develop high-level project requirements
 Initial
use-case and domain models (10-20%
complete)

Manage project scope
 Reduce
risk by identifying all key requirements
 Acknowledge that requirements will change

Manage change, use iterative process
N. Kokash, Software Engineering
6
Software Engineering
Inception




Define, implement and test interfaces of major components
Identify dependencies on external components and systems.
Integrate shells/proxies of them
Implement some key components (roughly 10% of code)
20% of use cases drive 80% of the architecture
Design, implement and test key scenarios for use cases
Verify architectural qualities


Less essential requirements may not be fleshed out
Drive architecture with key use cases


Transition
Produce an executable and stable architecture


Construction
Detail requirements as necessary (~80% complete)


Elaboration
Stress test (reliability), load test (scalability and performance)
Continuously assess business case, risk profile and
development plan
N. Kokash, Software Engineering
7
Software Engineering
Inception



Prototype system and involve end users
Incrementally evolve executable architecture to
complete system
Automate regression testing
Load and stress test to ensure architectural integrity
Deliver fully functional software (beta release)


Transition
Build daily or weekly with automated build process
Test each build



Construction
Complete requirements and design model
Design, implement and test each component



Elaboration
Includes training material, user and deployment
documentation
Produce release descriptions
N. Kokash, Software Engineering
8
Software Engineering
Inception
Elaboration
Construction
Transition
Produce incremental ‘bug-fix’ releases
 Update user manuals and deployment
documentation
 Update release descriptions
 Execute cut-over
 Conduct “post-mortem” project analysis

N. Kokash, Software Engineering
9
Software Engineering
Key principles and best practices
Develop Iteratively
Manage Requirements
Use Component Architectures

Develop only what is necessary



Minimize paperwork
Be flexible

Model Visually (UML)
Continuously Verify Quality





Feedback loops
Process improvement
Revisit risks regularly
Establish objective, measurable
criteria for progress
Automate

N. Kokash, Software Engineering
Requirements, plan, usage of people,
etc…
Learn from earlier mistakes

Manage Change
Lean process, agility
Support process with software
development tools
10
Software Engineering
Structured processes






Roles
Artifacts
Activities
Guidelines
Templates
Tool mentors
N. Kokash, Software Engineering
11
Software Engineering
Can a single process fit all these?
Higher
Technical
Complexity
Embedded
automotive
application
Telecom switch
DOD
weapon
system
National Air Traffic
Control System
Commercial
compiler
Lower
Management
Complexity
Large-scale
simulation
Small scientific
simulation
Web
application
Enterprise
information
systems
Higher
Management
Complexity
Web-based
on-line trading
system
Business
spreadsheet
Lower
Technical
Complexity
N. Kokash, Software Engineering
12
Software Engineering
Configurable processes
N. Kokash, Software Engineering
13
Software Engineering
Configurable processes
N. Kokash, Software Engineering
14
Software Engineering
RUP framework
Waterfall
Few risk, sequential
Late integration and testing
Relaxed
Little documentation
Light process
Low ceremony
Disciplined
RUP Process Framework
Light
RUP
Config.
Average
RUP
Config.
Large, more
formal RUP
Config.
Well-documented
Traceability
CCB
High ceremony
Iterative
Risk driven
Continuous integration and testing
N. Kokash, Software Engineering
15
Software Engineering
Model Driven Architecture (MDA)
Model
maintenance
implementation
transformation
Code
N. Kokash, Software Engineering
maintenance
16
Software Engineering
Essence of MDA
N. Kokash, Software Engineering
17
Software Engineering
Essence of MDA
N. Kokash, Software Engineering
18
Software Engineering
Example of MDA
N. Kokash, Software Engineering
Framework for the development of
new financial applications
19
Software Engineering
MDA tool types








Creation: elicit initial models and/or edit derived models.
Analysis: check models for completeness, inconsistencies,
or error and warning conditions, calculate metrics for the
model.
Transformation: transform models into other models or into
code and documentation.
Composition: compose (i.e., merge) several source models.
Test: test models using model-based testing approaches
Simulation: simulate the execution of a system represented
by a given model.
Metadata management: handle the general relations
between different models and the mutual relations between
these models.
Reverse engineering: transform particular legacy or
information artifact portfolios into full-fledged models.
N. Kokash, Software Engineering
20
Software Engineering
MDA Software Examples

M2M transformation: ActifSource, AndroMDA,
Mia Software Mia-Generation & MiaTransformation,



UI design tools: Eclipse E4/XWT, redView,
wazaabi
Application builders: BluAge, Mendix,
Outsystems Agile Platform, Sodius
MDWorkbench,




N. Kokash, Software Engineering
Eclipse Modeling Project: ATL, QVT
(Queries/Views/Transformations), xpand/xtend;
SysML: Artisan Studio,
.NET target: Aspectize, CodeFluent Entities,
Java Spring: SkyWay Builder, SpringRoo, Jaxio
Celerio & SpringFuse
CASE tools with MDE capabilities: ModelioSoft
Modelio, NoMagic MagicDraw, Sparx System
Enterprise Architect
21
Software Engineering
Software Product Lines



Developers are not inclined
to make a maintainable
and reusable product, it
has additional costs.
This viewpoint is changed
somewhat if the product
family is the focus of
attention rather than
producing a single version
of a product
Two processes result: domain engineering,
and application engineering.
N. Kokash, Software Engineering
22
Software Engineering
Process modeling

We may describe a software-development
process in the form of a “program” :
function review(document,
threshold): boolean;
begin prepare-review;
hold-review{document, no-ofproblems);
make-report;
return no-of-problems <
threshold
end review;
N. Kokash, Software Engineering
23
Software Engineering
State diagram of the
code review process
ready for the
next step
submit
coding ready
review
re-review
prepare
do
ready
done
make
report
ready
report
N. Kokash, Software Engineering
24
Software Engineering
Example: Framework to generate
Domain Specific Languages
N. Kokash, Software Engineering
25
Software Engineering
Petri-net view of the
code review process
code ready
hold review
from
code
update
revised code end next step
coding
from
management
scheduled
N. Kokash, Software Engineering
minutes
26
Software Engineering
Purposes of process modeling



Facilitates understanding and
communication by providing a shared
view of the process
Supports management and
improvement; it can be used to
assign tasks, track progress, and
identify trouble spots
Serves as a basis for automated
support (usually not fully automatic)
N. Kokash, Software Engineering
27
Software Engineering
Caveats of process modeling





N. Kokash, Software Engineering
Not all aspects of software
development can be caught in an
algorithm
A model is a model, thus a
simplification of reality
Progression of stages differs from
what is actually done
Some processes (e.g. learning the
domain) tend to be ignored
No support for transfer across
projects
28
Software Engineering
Modeling techniques

Traditional modeling
 Entity-relationship
diagrams
(ER)
 Finite state machines (FSM)
 Data-flow models
 Class-responsibilitycollaboration (CRC)

Object-oriented modeling
 Variety
N. Kokash, Software Engineering
of UML diagrams
29
Software Engineering
Entity-relationship modeling





Entity: distinguishable object of some type
Entity type: type of a set of entities
Attribute value: piece of information
(partially) describing an entity
Attribute: type of a set of attribute values
Relationship: association between two or
more entities
N. Kokash, Software Engineering
30
Software Engineering
Finite State Machines (FSM)


Models a system in terms of
a finite number of states and
transitions between those
states
Often depicted as state
transition diagrams:
 Each
state is a bubble
 Each transition is a labeled
arc from one state to another

N. Kokash, Software Engineering
Large system  large
diagram
31
Software Engineering
Data-flow modeling
External entity
Flow
Process
Data store
http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9
N. Kokash, Software Engineering
32
Software Engineering
Class-responsibility-collaboration
N. Kokash, Software Engineering
33
Software Engineering
What is an object?

Modeling viewpoint: model of part of
the world
 Identity

+ state + behavior
Philosophical viewpoint: existential
abstractions
 Everything



is an object
Software engineering viewpoint: data
abstraction
Implementation viewpoint: structure in
memory
Formal viewpoint: state machine
N. Kokash, Software Engineering
34
Software Engineering
Unified Modeling Language
(UML)



Object Management
Group (OMG)
consortium
Latest version: UML
2.2
14 diagram types:
 Static
diagrams
 Dynamic diagrams

N. Kokash, Software Engineering
Often loose semantics
35
Software Engineering
UML diagram types
N. Kokash, Software Engineering
36
Software Engineering
UML Use in Practice
N. Kokash, Software Engineering
37
Software Engineering
Structure diagrams







N. Kokash, Software Engineering
Class diagram describes the structure of a system
(classes, attributes, methods) and relationships
among the classes.
Component diagram shows the dependencies
among system components.
Composite structure diagram describes the internal
structure of a class and collaborations among its
parts
Deployment diagram describes the hardware used
in implementations and execution environments
Object diagram shows a complete or partial view of
the structure of a modeled system at a specific
time.
Package diagram shows the dependencies among
logical groupings.
Profile diagram operates at the meta-model level to
show stereotypes as classes and profiles as
packages
38
Software Engineering
diagram




Used both for conceptual and detailed
modeling
Classes, interfaces: class name, attributes,
methods
Visibility: public (+), private (-), protected (#),
package (~), derived (/), static
Relationships (links)
 Instance-level: association,
aggregation, composition
 Class-level: generalization, realization
 General: dependency
N. Kokash, Software Engineering
39
Software Engineering
Association
Bidirectional
 Unidirectional
 Reflexive

Aggregation
 Composition

N. Kokash, Software Engineering
40
Software Engineering
Aggregation and composition




N. Kokash, Software Engineering
Aggregation is a variant of the "has a"
or association relationship;
Composition is a stronger variant of
the “has a“ or association relationship
(assuming life cycle dependency);
Aggregation is more specific than
association;
Composition is more specific than
aggregation;
41
Software Engineering
Generalization
"is a“ relationship
 indicates that one of the two
related classes (subclass) is
considered to be a
specialized form of the other
(super type)

N. Kokash, Software Engineering
42
Software Engineering
Realization
Interface = class with abstract methods
 One model element (the client) realizes
(implements or executes) the behavior that
the other model

N. Kokash, Software Engineering
43
Software Engineering
Component diagrams




N. Kokash, Software Engineering
Like class diagram (stereotype
<<component>>)
Way to identify larger entities
One way to depict a module view
Components are connected by
interfaces
44
Software Engineering
Behavioral diagrams



N. Kokash, Software Engineering
Activity diagram describes the business
and operational step-by-step workflows
of components in a system. An activity
diagram shows the overall flow of
control.
UML state machine diagram describes
the states and state transitions of the
system.
Use case diagram describes the
functionality provided by a system in
terms of actors, their goals represented
as use cases, and any dependencies
among those use cases.
45
Software Engineering
Composite structure diagrams

Can be used to show:
 Internal
structure of a class
 Class interactions with environment through ports
 Possible collaborations of class parts
N. Kokash, Software Engineering
46
Software Engineering
Composite structure diagram
concepts






Part is a role played at runtime by one
or more instances of a class.
Port is an interaction point that can be
used to connect structured classifiers
Connector binds two or more entities
together
Collaboration defines roles that class
instances play
Structured classifier represents a class
whose behavior can be described
through interactions between parts.
Encapsulated classifier is a type of
structured classifier that contains ports.
N. Kokash, Software Engineering
47
Software Engineering
Deployment diagram

Nodes (boxes)
 Device
Node
 Execution
Environment Node
Subnodes
 Artifacts (rectangles)

N. Kokash, Software Engineering
48
Software Engineering
Object diagram


Some set of object instances, attributes and links
A correlated set of object diagrams provides insight into how an
arbitrary view of a system is expected to evolve over time.
N. Kokash, Software Engineering
49
Software Engineering
Package diagram
N. Kokash, Software Engineering
50
Software Engineering
Profile diagram

Can define:
classes
stereotypes
data
types
primitive types
enumerations
N. Kokash, Software Engineering
51
Software Engineering
diagrams

Graphical representations of
workflows





rounded rectangles represent
activities;
diamonds represent
decisions;
bars represent the start (split)
or end (join) of concurrent
activities;
a black circle represents the
start (initial state) of the
workflow;
an encircled black circle
represents the end (final state).
N. Kokash, Software Engineering
52
Software Engineering
State machines






Significantly enhanced realization
of the finite automata
Directed graphs in which nodes
denote states and connectors
denote state transitions
Extended states
Guard conditions
Actions
Stubs
N. Kokash, Software Engineering
53
Software Engineering
State machines: global and
expanded views
N. Kokash, Software Engineering
54
Software Engineering
Use case diagrams
N. Kokash, Software Engineering
55
Software Engineering
Interaction diagrams




Communication diagram shows the interactions
between objects or parts in terms of sequenced
messages.
Interaction overview diagram provides an overview
in which the nodes represent communication
diagrams.
Sequence diagram shows how objects communicate
with each other in terms of a sequence of messages.
Timing diagrams are specific types of interaction
diagram where the focus is on timing constraints.
N. Kokash, Software Engineering
56
Software Engineering
Communication diagrams
N. Kokash, Software Engineering
57
Software Engineering
Interaction overview diagrams
N. Kokash, Software Engineering
58
Software Engineering
Sequence diagrams

Consist of:
 Entities
(components
or objects, any order)
 Lifespans
 Messages
(synchronous &
asynchronous)
N. Kokash, Software Engineering
59
Software Engineering
Timing diagrams

Consists of:
 Lifelines
 State/condition
lifelines
 Duration constraints
 Time constraints

Destruction
occurrence
N. Kokash, Software Engineering
60
Software Engineering
Timing diagrams: example
N. Kokash, Software Engineering
61
Software Engineering

UML
 ArgoUML
(closely follows the UML standard)
 Umbrello UML Modeller
 ATL (transform UML models into other models)
…

UML2
 BOUML
(fast)
 Eclipse UML2 Tools (not all diagrams supported)
 StarUML (not under active development)
…
N. Kokash, Software Engineering
62
Software Engineering
Meta-modeling

N. Kokash, Software Engineering
Analysis, construction
and development of the
frames, rules,
constraints, models
and theories applicable
and useful for modeling
a predefined class of
problems.
63
Software Engineering
Meta-Object Facility
N. Kokash, Software Engineering
64
Software Engineering
Extensible Markup Language
(XML)
Set of rules for encoding documents
containing structured information in
machine-readable form
 Markup language much like HTML
 Designed to carry data, not to display data
 XML tags are not predefined. You must
define your own tags
 XML is designed to be self-descriptive

N. Kokash, Software Engineering
65
Software Engineering
XML example
<BOOKS>
<book id=“123” loc=“library”>
<author>Hull</author>
<title>California</title>
<year> 1995 </year>
</book>
<article id=“555” ref=“123”>
<author>Su</author>
<title> Purdue</title>
</article>
</BOOKS>
N. Kokash, Software Engineering
66
Software Engineering
XML Metadata Interchange (XMI)






Exchanging metadata information via XML
The most common use is an interchange
format for UML (although it can be used for
serialization of models of other languages)
XMI is a way to save UML models in XML
More generally, XMI shows how to save any
MOF-based meta-model in XML
Ability to move UML models between tools
XMI doesn’t (yet) specify how to record
graphical information; tools do this differently.
N. Kokash, Software Engineering
67
Software Engineering
N. Kokash, Software Engineering
68
Software Engineering
Programs that can open XMI files
N. Kokash, Software Engineering
69
Software Engineering

Modeling processes
 Focus
on control of the
development process
 Each situation requires its own
approach
 Help with reuse and
maintenance

Modeling notations
 Traditional
 UML
N. Kokash, Software Engineering
diagrams
70
Software Engineering
Read chapters 3.3-3.9, 10
 Design the Image2UML system using UML

 use
case, class, activity and statechart diagrams
N. Kokash, Software Engineering
71
Software Engineering
Software Engineering (3rd Ed.)


















N. Kokash, Software Engineering
1. Introduction
2. Introduction to Software Engineering Management
3. The Software Life Cycle Revisited
4. Configuration Management
5. People Management and Team Organization
6. On Managing Software Quality
7. Cost Estimation
8. Project Planning and Control
9. Requirements Engineering
10. Modeling
11. Software Architecture
12. Software Design
13. Software Testing
14. Software Maintenance
17. Software Reusability
18. Component-Based Software Engineering
19. Service Orientation
20. Global Software Development
72