CEN5087 Midterm Study Guide

• Models, Design, Tests

• A set of instructions (Programs)

Invisible Complexity - size Changeability - bugs, adding functionality, adapting

Low productivity Poor quality High Cost High Demand

Process Products Management Methods

Complexity - Abstraction (vertical) Divide & Conquer (Horizontal) Behavior Functionality Structure

System Engineering Software Requirements Analysis Software Design Coding & Unit Testing Integration & Integration testing Acceptance Testing Maintenance (Can't go back up past Maintenance)

+Simple, Straight sequence of phases

+It supports function-oriented project organization

-Inflexible to requirement change

-The system is outdated when delivered from long development duration

-No early feedback from the users

-May lose entire investment from customer if the project fails.

Inception: 1-2 iterations, produces a simplified use case model, a tentative architecture, and a project plan. Elaboration: Produces the most critical use cases and architectural design Construction: remaining use cases are implemented into the system Transition: System is deployed, users are trained, and bugs are fixed

+Flexibility

+Immediate feedback

-Scope creep

-Time

-Lack of predicitability

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Performance, reliability, usability, security, maintainability, quality.

Identifying problems and needs Constructing analysis models to help understanding Formulating system/software requirements Conducting feasibility study Checking the requirements and models for desired properties such as correctness, and consistency Specifying acceptance tests Formulating an iterative development plan

A business process that begins with an actor, ends with the actor, and accomplishes a business task useful for the actor.

Usually a circle.

Played by and on behalf of a set of business entities or stakeholders that are external to the system and interact with the system.

Usually a stick figure

It encloses the use cases and show the capabilities of the system.

Usually a box.

Indicates that one use case is more general/specialized than the other.

Notation: -

⇨

Indicates that one use case can optionally continue the process of another use case.

Notation ----> <<extend>>

Indicates that one use case includes another use case as part of its business process

----> <<include>>

The modeling and design of how the system interacts with the actors to carry out the use cases. A two-column table that describes each interaction (actor input and system response)

using a verb or noun phrase

stating exactly when and where the use case begins and when it ends. (This use case begins with, This use case ends with)

describing step by step how the actor and system interact to accomplish the business task using a two-column table

use case assumes that the actor has already taken action that does not directly interact with this use case

system changes based on the completion of use case

Diagrams that are a more understandable visual representation than textual description. Show use cases with multiple scenarios and use cases with concurrent activities.

An abstraction of objects with similar properties and behavior. A collection of objects.

defines properties and operations for an association between two classes

Inheritance, Aggregation, Association

expresses the generalization/specialization relations between concepts. One concept is more general/specialized than the other. IS-A relationship

Example: Vehicle is a generalization of car, car is specialization of vehicle

expresses the fact that one object is part of another object. Also called PART-OF relationship

Example: engine is part of a car

expresses general relationship other than inheritance and aggregation. Can be application specific relationships between two concepts

Example: instructor teach course, user has account

High-level system structural organization that consists of a collection of components, their interactions (connectors), and constraints.

Important because it helps with better understanding of the system and enables as early system level analysis. The "blueprint." Facilitates maintenances and future system evolutions

Interactive, event-driven, transformational, object-persistence

interaction between system and actor consists of a relatively fixed sequence of actor requests and system responses.

Actor and system have a "client-server" relationship.

System has to process and respond to each request.

interacts with more than one external entity at the same time.

Receives events from, and controls external entities

Does not need to respond to every incoming event. Its response is state dependent - the same event may result in different responses depending on system state

consist of a network of information-processing activities, transforming activity input to activity output

Activities may involve control flows that exhibit sequencing, conditional branching, parallel threads, synchronous and asynchronous behavior

systems may perform number crunching or computation intensive algorithms

Provides object storage and retrieval capabilities to other subsystems

Responsible only for storing and retrieving objects, and does little or no business processing except performance considerations

Hides implementation from the rest of system

o define the computation logic and data organization: objects, databases, filters, clients, and servers

define the interactions among components: procedure call, access protocol, and pipers

define system level properties: pre-post conditions, safety properties, liveness properties