advanced topics in software construction atsc 01 object ...€¦ · functional requirements...

Advanced Topics in Software Construction

Prof. Armin B. Cremers, Daniel Speicher, Jan Nonnen, Paul Heckmann

ATSC 01

Object Oriented Software Construction

A T S C A Simplistic Example

Computer Science III Advanced Topics in Software Construction 2012 3 / 60

Requirements Elicitation, Domain

are for a guest.


Requirements Elicitation, Scenarios


Requirements Elicitation, Use Case Model


Requirements Analysis


System Design


Object Design


Software Development Process, “Waterfall”

Sub- systems

class...

class...

class...

Source Code

Solution Domain Objects

System Design

Object Design

Implemen- tation

Testing

ApplicationDomain Objects

Test Cases

?

class.... ?

Requirements Elicitation

Use Case Model


Expressed in Terms of

Structured by

Realized by

Implemented by

Verified by


Overall shape of the V-Model process



System Design

Object Design

Implementation

Unit Testing

Integration Testing

System Testing

Acceptance Testing

Application Domain

Solution Domain

„V-Model“


Application and Solution Domain: Object-oriented modeling

Application Domain Solution Domain

Application Domain Model System Model

Use Case Diagram Class Diagram

Sequence Diagram Activity Diagram

State Diagram


Application and Solution Domain

Application Domain (Requirements Analysis)

Incorporates physical environment, users and their work processes in which the system should operate,

Application Domain Model

Solution Domain (System Design, Object Design)

Embraces models that describe possible solutions for a software systems that are appropriate for operating (supporting) in the application domain.

System Model

A T S C Complexity and Change

Addressed by Separation of Concern and Minimizing

the semantic gap between domains and models


Multiple Stakeholders!


Multiple Machines & Technologies!


More Functionality, Corrections


It‘s not that simple: Multiple Functionalities

Requirements:

Hotel Management System

Main Functionality: Handle Reservations, Check In, Check Out

Variations:

High Class Hotels: Includes database of special wishes of customers (chocolate, flowers, …).

Budget Hotels: Has to manage more than one guests per room.

Wellness Hotels: Includes modules to manage facilities, book massages, …

The system should be responsive, highly available, keep the privacy of customer data, easy to use.

Functional Requirements

Non-Functional Requirements

Software Systems are complex and requirements and technology

are changing.

To handle the complexity we need to be able

to think about different concerns separately.

[Domain] Modeling

[Technical] Architecture

Technologies like Components, MDA, AOSD make separation possible.


Means to handle Complexity and Change

Separation of Concern

Functional vs. Non-Functional Requirements

Information Hiding (Interfaces vs. Implementation)

Abstraction (Domain Model)

Decomposition (Whole vs. parts within a model)

Hierarchies (General vs. special cases within a model)

[MDA and AOSD support SoC]

Minimize semantic gap between domains and models

“Domain Driven Design”, “MDA”, Domain Specific Languages

Conceptual Integrity, OOA/D

Requirements Engineering!

The “parts” are easier to understand and to change


Outline of the lecture [Domain] Modeling

[Technical] Architecture

Overall Process


About the rest of today‘s lecture

Reminder of what you should already know

Not completely required for this lecture

Necessary to become a good Software Engineer

Follows the Software Engineering Process



System Design

Object Design

Implementation

Testing

Deeper Discussion of “Abbott’s method”, Analysis Object Model, Some Design Pattern


The diagrams of UML 2 in this lecture

Class diagram

Object diagram

Package diagram

Component diagram

Composite structure diagram

Deployment diagram

Structure diagram

UML diagram

Behavior diagram

Sequence diagram

Communication diagram

Use Case Diagram

Activity Diagram

State Machine Diagram

Interaction diagram

Timing diagram

Interaction overview diagram

Should be known, will be repeated.

Will be introduced in this lecture.

Should be known.

Low priority.

Color code:

Changed from UML 1.4 to 2

New in UML 2

A T S C Requirements Elicitation


Tool: Brainstorming

Process of systematic and liberal generation of a large

volume of ideas

Participants are encouraged to provide creative inputs in

an atmosphere that is free of criticism and judgment

from other participants.

Unstructured brainstorming

Participants can give ideas as these come to mind

Quite often not very efficient

Structured brainstorming

Participants must follow a policy in order to make the

gathering of inputs more orderly and more efficiently.


Brainstorming The benefit of the no-early-criticism rule

Idea 2

Idea 3

Criterion A Criterion B

Idea 1

Idea 2

Idea 3

Idea 4

Idea 5

Idea 6

Idea 7

Criterion C Criterion A

Criterion B

Idea 1

Without the rule: Fewer ideas, evaluated against fewer criteria. Process stops early.

Special case of point-based vs. set-based thinking. [Lean Development, Tool 6, Lecture about Agile Software Development].


FURPS+

F unctional Requirements

U sability

R eliability Dependability, Robustness, Safety

P erformance Response time, Throughput, Availability, Accuracy

S upportability Adaptability, Maintainability

+

Implementation requirements

Interface requirements

Operations requirements

Packaging requirements

Legal requirements

Literature: [BD09] 4.3.2 “Non-functional Requirements”,

Table 4-3 in 4.4.7 “Identifying Non-functional Requirements”,

4.6.5. Table 4-3 applied to an example

Program Input Output


Process of Requirements Elicitation: The Requirements Elicitation Cycle

Use Cases +

Refinements

Observing users As-Is Scenarios

Validation

Interviewing

users and clients

Visionary

Scenarios

Validation

Validation

Validation

Stable Requirements Specification

(System Specification)

• Functional Requirements

Non-Functional Requirements

Use Cases

Scenarios

Tests

Validation

Prototypes


Scenarios: Different Types

As-is scenario

Used in describing a current situation

Usually used in re-engineering projects

The user describes the system

Visionary scenario

Used to describe a future system

Usually used in Greenfield engineering and reengineering projects

Can often not be done by the user or developer alone

brainstorming sessions

needs and possiblities

Evaluation scenario

User tasks against which the system is to be evaluated

Training scenario

Step by step instructions that guide a novice user through a system


Example: Use Cases Diagram of Hotel System

Check In

Customer

Check Out

Customer

Handle

Waiting

List

«extend»

Check

Room

Details

«include»

Reserve Room

Extension Point

Update Room

Availability

«include»

«include»

Hotel System

Counter Staff

Application Application Base

Customer Application

Counter Staff

Guest

A T S C Requirements Analysis

Domain Object Model

Analysis Object Model


Domain Object Model: Abbott Textual Analysis [Abbott, 1983]

Set of heuristics for identifying objects, attributes and associations from a requirements specification

Mapping of parts of speech to model components

Nouns are good candidates for classes

Verbs are good candidates for operations

… and further more specific mappings (next slide)

In the problem statement (originally proposed, but rarely works if the problem statement is large (more than 5 pages)

Quality depends on style of writing

Too many nouns

In the flow of events of use cases (preferable)

Small list of candidate objects


Mapping parts of speech to object model components

Part of speech Model component Example

Proper noun object Jim Smith

Common noun class person, car

Doing verb method buy, enter, drive

being verb inheritance is-a, either .. or

having verb aggregation has an

modal verb constraint must be

adjective attribute (association) causing,3 years old

transitive verb method enter [a building]

intransitive verb method (condition) break (is broken)


Domain Object Model: Identifying Participating Objects

Pick a use case and look at its flow of events

Find terms that developers or users need to clarify in order to understand the flow of events

Look for recurring nouns (e.g., Room),

Identify real world entities that the system needs to keep track of (e.g., Customer, Receipt, Resource),

Identify real world procedures that the system needs to keep track of (e.g., RoomReservation),

Identify data sources or sinks (e.g., Printer)

Be prepared that some objects are still missing and need to be found:

Model the flow of events with a sequence diagram (later..)

Always use the user’s terms


Domain Object Model: Analyzing the Common Nouns (Classes)

Traffic accidents have a time and a location.

A traffic accident has one causing car and one affected car.

A person can drive a car.

Besides the driver a car has an owner.

Persons hold insurance policies.

Person, which are owners of a car, must hold liability insurance policies (which are insurance policies as well).

In a traffic accident at the beginning of October in Bonn the causing car was driven by Andrew and owned by Boris, while the affected car was driven by Chris who owns it as well.


Domain Object Model: Analyzing the Doing Verbs (Methods)









Domain Object Model: Having & Being Verbs (Aggregation/Inheritance)









Domain Object Model: Analyzing the Adjectives (Attributes/Aggregation)









Domain Object Model: Analyzing Modal Verbs (Constraints)









Domain Object Model: Analyzing the Proper Nouns (Objects)









Grammatical construct

UML Component

Proper noun Object

Common noun class

Doing verb Method

Being verb Inheritance

Having Verb Aggregation

Modal Verb Constraint

Adjective Attribute

Method

Domain Object Model: Overview of Analysis

Example

“Bonn”, “Boris”

“car“, “traffic incident”, “person”

“drive”

“are“ , “type of…”

“has a ", “hold”

“must be“ , “less than”

“causing“, ”affected”


Domain Object Model: Class Diagram (First Iteration)

TrafficAccident Time

Location

Car

causing

affected

Person

Owner Driver

InsurancePolicy

LiabilityInsurancePolicy

holds

*

holds

1..*

1

1

1

1

What if owner and driver are the same person?

drive()


Domain Object Model: Class Diagram (Second Iteration)

TrafficAccident

causing

affected

Person InsurancePolicy

LiabilityInsurancePolicy

holds

1

1

1

1

Car

owner

driver

time:String location:String

ownedCar

*

*

*

{ person.ownedCar->size() >0 implies person.insurancePolicies->exists (p | p->isInstanceof(LiabilityInsurancePolicy)) }

{ If Person owns a car, he/she holds at least one LiabilityInsurancePolicy. }

drivenCar

drive()


Domain Object Model: Object Diagram

:TrafficAccident

affected

causing Andrew:Person causingCar:Car

time:“Begin of October“ location:“Bonn“ affectedCar:Car Boris:Person

Chris:Person

owner

driver

owner

driver


Identifying Key Objects: Entity Objects

Represents persistent or long-lived information tracked by the system

Real-World entities from application domain (Counter Staff, Customer)

Real-World activities the system needs to track (Receipt, Reservation)

Recurring Nouns that are used in the UCs

Represent the persistent information tracked by the system (Application domain objects,

“Business objects”)


Identifying Key Objects: Boundary Objects

System interface for the actors

Forms, Messages, Terminals for different users

Identify Forms the user needs to enter data into the system

Identify messages the system uses to respond to the user

Interface for external systems (e.g. online payment)

Data Sources or Sinks

Described in End User Terms

Good: CheckoutForm, ReserveButton

Bad: MenuItem, ScrollBar (too detailed)

Represent the interaction between the user and the system


Identifying Key Objects: Control Objects

Responsible for coordinating boundary and entity objects

Collecting information from boundary objects

Dispatching it to entity objects

Control of distributed systems

The internal workflow of a system

Heuristic: One Control Object per Use Case (no counterpart in real world)

Life span covers the extent of a use case (user session)

Represent the control tasks performed by the system


Example: Use Cases Realizations

Handle

Waiting

List

«extend»

Check

Room

Details

Check Out

Customer «include»

Reserve Room

Extension Point

Update Room

Availability

«include» Check In

Customer «include»

Hotel System: Use Case Model

Counter Staff

Application Application Base

Customer Application

Hotel System: Analysis Model

Room

Customer

Main Form

Reservation Staff

Main Form

Room

Customer

Main Form

Reservation Staff

Main Form

Check Room

Details Handler

Room Details

Form

Room

Customer

Main Form

Reservation

Check In

Handler Staff

Main Form

Check Out

Handler

Check Room

Details Handler

Room Details

Form

Reserve Room

Form

Room

Customer

Main Form

Reservation

Reserve Room

Handler

Check In

Handler Staff

Main Form

Check Out

Handler

Check Room

Details Handler

Room Details

Form

Reserve Room

Form

Room

Customer

Main Form

Waiting

List

Waiting List

Handler

Reservation

Reserve Room

Handler

Check In

Handler Staff

Main Form

Check Out

Handler

Check Room

Details Handler

Room Details

Form

A T S C System Design


Tool: Rationale Management

For an issue certain criteria are relevant. Proposals that address the issue are assessed by these criteria. Of course a proposal can address more than one issue. Based on the proposals a resolution has to be selected, which resolves the issue. Of course new issues might be raised by proposals.


Activities during System Design

Identify Design Goals

Sub system decomposition

Partitions vs. Layers

High Cohesion! Low Coupling!

Hardware / Software Mapping

Define Data Persistency

Define Access Control

Design Global Control Flow

Find Boundary Conditions

Anticipate Change


Software Architectural Styles

Typical high level structures of systems. (Typical parts and how they interact.)

Repository (Blackboard Architecture)

Model/View/Controller

Client/Server

Peer-to-Peer

Three Tier

Pipe and Filter

Service-Oriented Architecture (SOA)

A T S C Object Design


Design Principles

Information Hiding

Liskov Substitution Principle

Favor Delegation over Inheritance

Design by Contract

Preconditions must be true before the operation is invoked.

Caller must meet precondition before calling.

Postconditions must be true after an operation is invoked.

Called object must ensure after the operation execution.

Class Invariant: Assertion about all instances of the class at all “stable” times.


Design Pattern

Creational Design Pattern

Abstract Factory, Builder, Factory Method, Prototype, Singleton

Structural Design Pattern

Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy

Behavioral Design Pattern

Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, 1994

A T S C Implementation


Realizing Associations

Strategy for implementing associations

Be as uniform as possible

Individual decision for each association

Example of uniform implementation

1-to-1 association:

Role names are treated like attributes in the classes and translate to references

1-to-many association:

"Ordered many" : Translate to (Array)List

"Unordered many" : Translate to (Hash)Set

Qualified association:

Translate to Hashtable


Realizing Inheritance in Relational Databases

Relational databases do not support inheritance

Three possibilities to map UML inheritance relationships to a database schema

With a separate table (vertical mapping, table per subclass )

The attributes of the superclass and the subclasses are mapped to different tables

By duplicating columns (horizontal mapping, table per concrete class)

There is no table for the superclass

Each subclass is mapped to a table containing the attributes of the subclass and the attributes of the superclass

Single table per class hierarchy

All classes of a hierarchy are mapped into the same table

A T S C Testing


What you should already know

Testing terminology: Test Case, Test Stub, Test Driver

Black Box Testing

Equivalence Classes, Boundary Cases

White Box Testing

Statement-, Branch-, Loop-, Path-, Basic Path-Coverage

Unit Testing

System Testing

Integration (Big Bang, Top Down, Bottom Up), Functional, Performance, Installation, Acceptance Test


Literature

Reference: “The Unified Modeling Language User Guide”, Addison Wesley, 2005.

“UML Distilled” (Fowler & al. 2000, Addison Wesley) – Short and nice!

“UML@Work“ (Hitz & Kappel 2005, dpunkt) – UML 2.0, German only , Extensive!

You can use the UML slides from the OOSC 2012: https://sewiki.iai.uni-bonn.de/teaching/lectures/oosc/2012/schedule

Supported by several CASE tools: Rational Rose, Eclipse, TogetherJ, Visual Paradigm, Astah

https://sewiki.iai.uni-bonn.de/teaching/lectures/oosc/2012/schedule




Software Development Process, “Waterfall”

Sub- systems

class...

class...

class...

Source Code

Solution Domain Objects

System Design

Object Design

Implemen- tation

Testing

ApplicationDomain Objects

Test Cases

?

class.... ?


Use Case Model


Expressed in Terms of

Structured by

Realized by

Implemented by

Verified by

advanced topics in software construction atsc 01 object ...€¦ · functional requirements...

Documents