01 Introduction

Object-Oriented Analysis and Design
Session 1: Introduction
Mira Balaban and Arnon Sturm
Course Goal
The course aims at teaching the analysis and design of software systems Analysis means who will use the system, what the system will do, where and when it will be used. Design means how the system will be built and operate, in terms of hardware and software.
Outline
1. Software System Characteristics - Requirements and Solutions.... 4 2. Development Processes ...20 3. The Unified Process .33 4. Modeling Languages ....39 5. The Unified Modeling Language .48 6. Course Plan ..54
Software System Characteristics Requirements and Solutions
What is a software system?

Computer programs and associated documentation:
Requirements; Analysis and Design models; User manuals;
Software products may be

Generic - developed to be sold to a range of different customers: PC software such as Excel or Word. Bespoke (custom) - developed for a single customer according to their specification.
A Case Study The Library System

Computerize the university library. Build it as an interactive online system.
Books and journals - Several copies of a given book. - Short-term loans. - Long-term week loans. - Only staff members can borrow journals. - An individual can borrow up to 6 books at a time. - Staff can borrow up to 12 books at a time. Searching Borrowing Track when books are borrowed and returned. Issue reminders. Possible future requirement for loan-extension functionality.
Mira Balaban and Arnon Sturm Object-Oriented Analysis and Design
Characterization of a Good System (1)
Useful and usable

The library may be operated by less people. The students will be able to order books.
Reliable
The system should mark the right ordered book for a specific student.
Flexible (modifiable) and easy maintenance

It would be easy to add new requirements such as dealing with CDs.
Affordable
The university has allocated the right budget to develop the system.
Available
The system should work 7 days a week.
Characterization of a Good System (2)

Difficulties: Our understanding of systems is usually partial:
It is not trivial to understand the tracking mechanism.
We tend to misinterpret casual properties as characteristic ones:

A borrower account number is not essential to the system.
We tend to solve problems locally:

Developing an additional search mechanism within the order processing.
We tend to solve whole problems. Small changes in specifications lead to reconstruction of the whole system:
The system is planned to support only books and journals. Addition of CDs implies changes to the design (and code).
A Key for Building a Good System: Modularity

A modular system consists of : encapsulated modules with dependencies among them.
Encapsulation and Abstraction

Encapsulation: When a client is not able to know more than is in the Interface. Abstraction: When a client does not need to know more than is in the interface declared services For example: Core Module List and its Client Queue Abstraction/encapsulation are essential for modularity
10
A measure for abstraction: Cohesion

Cohesion is the amount of coherency of a module a module needs a main theme: Theme 1 - Borrowing Theme 2 - Searching
High cohesion is a major pattern (advice) in assigning responsibilities to modules Good abstraction implies reuse Pluggable components.
11
What is Dependency?
Module A depends on module B if changes to module B can imply changes to module A: A is a client of B A use services of B; B acts as a server to A
Ordering depends on Searching Important information for a module:
Which modules are its clients? What assumptions clients make about it? Which modules are its servers?
12
A measure for dependency: Coupling

Coupling is the amount of dependency among modules.
A system with many dependencies has high coupling. Good systems have low coupling.
Low coupling is a major pattern (advice) in assigning responsibilities to modules.
13
Achieving Modularity
Interface is the means for achieving modularity: Interfaces encapsulated modules Interface of a module: Encapsulates knowledge about a module. Defines features on which clients can rely. Contract of a module Declares the responsibilities of a module (interface, services, constraints). States the context dependencies of a module -the services it requires in order to work.
14
Layering
A common technique for breaking apart complex software systems.
Machine architectures: Programming languages + Operating systems. Device drivers + CPU instructions. Logic gates inside chips. Networking: FTP TCP IP Ethernet.
Principles:
Higher layers use services of lower layers. Lower layers are unaware of their higher layers. Each layer hides its lower layers from its super layers.
15
Pros. and Cons. of Layering

Pros.
Understand one layer independently of other layers: Abstraction Replace layers with alternative implementations. Minimize dependencies between layers. A layer can be used for multiple purposes in higher layers Information systems
Cons.
Reduce efficiency: Translation takes time. Changes in a higher layer propagate downwards. Addition of a field in a user interface propagates down to the database layer instead of a direct database schema revision.
16
The Three Principal Layers

Layers Presentation Responsibilities
Display information windows, HTML. Handle user/communication requests mouse, keyboard, command line.
Domain Logic
(business logic)
Application core
Data source
Persistent data storage (Data base, files)
17
Splitting Information among Layers (1)

Example: Find the award winning staff member serves maximal number of book loans. Bad splitting: (no splitting) 1. The UI layer access the database for all staff members and the number of book loans they each handled. 2. It then finds the maximal number of book loans. 3. Finally, it finds the corresponding staff member and singles it with a red color.
Drawbacks: Change in the awarding policy implies changes in the UI layer. If the awarding policy is duplicated (e.g., for communication with the Human Resource department) than policy change implies multiple revisions (consistency problems). Change in the singling-out technique implies system changes.
18
Splitting Information among Layers (2)

Good splitting:
UI Layer asks Domain Layer for the winning staff member. Domain Layer asks Data Layer for all staff members and the number of book loans they handled. Domain Layer determines the award winning staff member according to the awarding policy. Domain Layer asks the UI Layer to single out the award winning staff member. UI Layer singles out the award winning staff member with a red color.
Advantages:
Changing the awarding policy affects only the domain layer in a single point (3). Change in the singling-out technique (5) does not affect the rest of the system.
19
Development Processes
20
What is a software development process?
An organized set of activities whose goal is the development or evolution of software. Generic activities in all software development processes are:
Specification - what the system should do and its development constraints. Development - production of the software system. Validation - checking that the software is what the customer wants. Maintenance - changing the software in response to changing demands.
Software development processes yield better software systems.
21
Variety of development processes

A variety of development processes have been studied and experimented in the field of Software Engineering:
Waterfall. Evolutionary development. Component based development. Incremental development. Spiral development. Agile development.
Development processes differ in the involved activities, their duration and ordering.
22
Waterfall model (1)

Requirement Verification
Analysis Verification Design Verification Implementation Verification Requirement Change Verification
Integration Verification Operational

development maintenance
End of use
23
Waterfall model (2)

Problem Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Applicability This model is only appropriate when the requirements are well-understood and changes are fairly limited during the design process.
24
Evolutionary development (1)

Objective is to work with customers and to evolve a final system from an initial outline specification.
Requirement Identification Prototype Development Prototype Use and Evaluation Prototype Improvement Operational End of use
25
Evolutionary development (2)

Applicability: For small or medium-size interactive systems. For parts of large systems (e.g. the user interface). For short-lifetime systems. Problems: Lack of process visibility. Systems are often poorly structured. Special skills (e.g. in languages for rapid prototyping) may be required.
26
Component-based software engineering

Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Process stages:
Component analysis. Requirements modification. System design with reuse. Development and integration.
Becomes popular as component standards are emerging.
27
Incremental development (1)

Development and delivery is broken into increments: Delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments.
28

Build 1
Analysis
Build
Design
Analysis
Implementation & Integration

Delivery
Design
Build
Implementation & Integration Delivery
Analysis
Design
Analysis Group Design Group Implementation Group

Implementation & Integration
Delivery
29

Advantages System functionality is available earlier. Early increments act as a prototype: Help elicit requirements for later increments. Lower risk of overall project failure.
30
Spiral model an incremental process

planning risk analysis
artifacts customer evaluation

engineering
31
The Agile Development Movement

An incremental software development movement that aims at shortening the development phases: Lightweight few documents and models. Fast implementation. Correlation between models and software.
The most well known agile development process -Extreme Programming (K. Beck): Minimal development phases. Test Driven Development (TDD).
32
The Unified Process

(Booch, Jacobson, and Rumbaugh The Rational initiators )
33
Unified Process (UP)

Characterization of the UP: Incremental. Iterative. Use-Case Driven Development follows stories of software usage. Architecture-Centric Software development is centered around system architecture (and not functionalities).
34
Incremental Iterative Aspects of UP

Software is developed in distinct iterations. Each iteration extends the previous. Each iteration might involve different activities. Iterations at early stages of software development differ from iterations at later stages.
In the Library example:

First iteration might produce: Analysis of major library concepts Librarian, Book, Book-Copy, Book-Loan. Simple book borrowing functionality. Second iteration: Complex book borrowing functionalities. Third iteration:
35
Incremental Iterative Aspects of UP

Advantages: Risks are mitigated earlier. Change is more manageable. There is a higher level of reuse. The project team can learn along the way. Managed complexity. Early visible progress. Early feedback.
36
The Unified Process Official Description
37
Phases and Workflows in the UP

The vertical dimension (workflows) specifies the process components and artifacts. The horizontal dimension (Phases) represents the dynamic aspect of the process and shows its lifecycle. Workflow vs. Phase
Workflow is presented in a technical context. Phase is presented in a business context.
38
Modeling Languages (also called Models)
39
Modeling Objectives
Visualize a system as it is or as we want it to be. Specify the structure or behavior of a system. Provide a template that guides system construction. Document decisions that we have made.
40
The Modeling Scenario

Developer
View View
Real World
Conceptual Model
Meaning Mapping (semantics)
Modeled Phenomenon
Software Construction
41
Historical View on Modeling Languages

1960s Output-oriented methods 1970s Process-oriented methods (Structured System Analysis and Design SSAD): Use DFDs Data Flow Diagrams. 1980s Data-oriented methods: Use ERDs Entity-Relationship Diagrams. 1990s Object-oriented methods (OMT, OOD, OOSE, UP): Standard: UML Unified Modeling Language.
42
Structured System Analysis and Design

Hierarchical functional system decomposition: Decomposition by system processes. Development methodology: Waterfall. Visual Modeling languages: Data Flow Diagrams (DFDs). Entity relationship diagrams (ERDs). When Appropriate? Small systems. No Domain Logic layer.
43
Structured System Analysis and Design
Example: In the Library information system: System is broken by processes into: Return/Loan, AddResources, reportFines, ...
44
The Object-Oriented (OO) Approach

Structure is more stable than processes. Preferable: Systems that are structure-oriented over systems that are solution/process-oriented. System is decomposed by objects. Focus is on: Responsibilities and roles of objects. Co-operation and collaboration between objects. Development methodology: Iterative. Visual languages: UML When Appropriate? -- Rich Domain Logic layer.
45
The Object-Oriented (OO) Approach

Example: In the Library information system: System is broken by the object model into: Classes: Book, Copy, LibraryManager,... Association: borrow/return, ... Processes: Return/Loan, AddResources, reportFines, by assigning responsibilities to objects.
46
Importance of Modeling Languages

The modeling language that expresses the problem domain influences the overall solution. Language refinement: Every model may be expressed at different levels of precision. A modeling language must be connected to reality. Belief: No single modeling language is sufficient for the specification of complex systems.
A small set of nearly independent modeling languages is required
47
The Unified Modeling Language (UML)

started at 1995
48
What Is the UML?

The Unified Modeling Language (UML) is a family of independent languages for
Specifying Visualizing Constructing Documenting
different aspects of a software-intensive system.
49
UML Goals
Define an easy-to-learn but semantically rich visual modeling language. Unify existing Object-Oriented modeling languages: Booch, OMT, and OOSE modeling languages. Incorporate industry best practices.
50
The UML Visual Languages

State State Diagrams Class Diagrams Diagrams
Use Case Use Case Diagrams Activity Diagrams Diagrams
Use Case Use Case Diagrams Use Case Diagrams Diagrams
State State Diagrams Object Diagrams Diagrams
Scenario Scenario Diagrams Sequence Diagrams Diagrams
Model
State State Diagrams State Diagrams Diagrams
Scenario Scenario Diagrams Collaboration Diagrams Diagrams
Deployment Diagram
Component Component Diagrams Component Diagrams
Diagrams
51
The UML Modeling Languages

Requirements engineering languages:
Use-cases and use-case diagrams. Activity diagrams.
Structure (static) modeling languages:

Class diagrams. Object diagrams.
Behavioral (dynamic) modeling languages:

Sequence diagrams; collaboration diagrams. Statecharts.
Implementation level languages:

Deployment diagrams. Component diagrams.
Object Constraints Language (OCL).

52
The UML Modeling Languages

In this course we teach software modeling in various stages of software analysis and design. We use the following UML languages:
Use-cases and use-case diagrams. Activity diagrams (very shortly). Class diagrams and object diagrams: In much detail. Sequence diagrams, collaboration diagrams; Statecharts. Object Constraints Language (mainly the static aspects).
53
Course Plan
Structural Modeling
Class and Object Diagrams UML extension mechanism (applied to the static part) Meta modeling Object-Constraint Language (applied to the static part)
Behavioral Modeling
Modeling object interaction Sequence and Collaboration Diagrams Modeling object behavior State charts Modeling cross object behavior Activity Diagrams
Development Process
Requirements gathering, modeling and implementing System Layering
54

01 Introduction

Uploaded by

Document Information

Original Description:

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

01 Introduction

Uploaded by

Copyright:

Available Formats

Object-Oriented Analysis and Design

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Software System Characteristics Requirements and Solutions

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

What is a software system?

Software products may be

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

A Case Study The Library System

Characterization of a Good System (1)

Useful and usable

Flexible (modifiable) and easy maintenance

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Characterization of a Good System (2)

We tend to misinterpret casual properties as characteristic ones:

We tend to solve problems locally:

A Key for Building a Good System: Modularity

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Encapsulation and Abstraction

A measure for abstraction: Cohesion

A measure for dependency: Coupling

Low coupling is a major pattern (advice) in assigning responsibilities to modules.

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Pros. and Cons. of Layering

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

The Three Principal Layers

Persistent data storage (Data base, files)

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Splitting Information among Layers (1)

Splitting Information among Layers (2)

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

What is a software development process?

Software development processes yield better software systems.

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Variety of development processes

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Waterfall model (1)

Integration Verification Operational

Waterfall model (2)

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design

Evolutionary development (1)

Evolutionary development (2)

Component-based software engineering

Becomes popular as component standards are emerging.

Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design