IS 341

Business Systems Analysis

Appendix A - Notes

Object-Oriented Analysis and Design

***NOTE: We are only going to focus on Object Modeling in its most basic form, with the intent of picking up the basics of object modeling and terminology.

I. The Object-Oriented Modeling Approach – object modeling still delivers ERDs, DFDs, and Repository Descriptions, but they are much more tightly linked in object methodology; Benefits of object modeling:

1. Ability to tackle more challenging problem domains

2. Improved communication among users and developers (analysts, designers, and programmers)

3. Reusability of analysis, design, and programming results

4. Increased consistency among the models developed during object-oriented analysis, design, and programming.

An object-oriented SDLC focuses on a progressively developing representation of a system component (called an object); early stages are abstract, focusing on external qualities (data structures, timing, user interaction); later stages focus on functionality.

The analysis phase models important real-world properties and what the object should do (not how), on functional behavior independent of the environment.

In the design phase the application-oriented analysis model is adapted/refined to fit the target environment.

During the implementation phase the finalized design is implemented using a programming language or DBMS.

Unified Modeling Language (UML) – special notations (and techniques) that allow the modeler to specify, visualize, and construct the artifacts of software systems and business models; it builds upon and unifies the semantics and notations of leading object-oriented methods and has been adopted as an industry standard.

UML is used for graphically representing object-oriented analysis and design models, specifying system requirements and design decisions, and promoting communication among developers, users, and others stakeholders. The underlying model integrates various views so the systems can be analyzed, designed, and implemented in a complete and consistent fashion.

II. Use-Case Modeling – used to analyze functional requirements of a system; consists of Actors and Use Cases

Actor – an External Entity that interacts with the system; represents a way that a user can use the system; the Actor’s Name should indicate the action

Use Case – a Complete Sequence of related actions initiated by an actor, representing a specific way to use a system

In a Use Case an Actor initiates a sequence of related actions, a specific way of using the system; an analyst should spend time with a user and understand the actions that the user could request of a system, then build all these possibilities into the system in terms of Use Cases; Use Case models can be used by programmers for developing the actual system

III. Object Modeling: Class Diagrams

Object – an entity that has a well-defined role in the application domain; has State, Behavior, and Identity; it makes sense in an application context; may be tangible or intangible, a person/place/thing/event or anything at all

State – a condition that encompasses an object’s properties (attributes and relationships) and the values of those properties – what does the object “look like”

Behavior – the way an object acts and reacts (methods/services/programs)

Object Class – a set of objects that share a common structure an behavior

Class Diagram – shows the static structure of an object-oriented model – the class, its internal structure, and its relationships

Object (Instance) Diagram – graphical representation of instances compatible with a given object class

Operation – a service/method/function provided by all instances (members) of a class

Encapsulation – hiding the internal details of an object from external view

Representing Associations

Association – a relationship among object classes; unary, binary, ternary, etc

Association Role – the end of an association where it connects to a class; may be named

Multiplicity – how many objects participate in a given relationship

IV. Representing Generalization –

A. Subclasses and Superclasses

B. Inheritance

C. Abstract and Concrete Classes

1. Abstract Class – has no direct instances, but its descendants may have direct instances – a class, Patient, has no direct instances, but has two subclasses, Inpatient and Outpatient, both of which may have direct instances

2. Concrete Class – a class that can have direct instances - Inpatient and Outpatient

V. Representing Aggregation

Aggregation – a “part-of” relationship between a component object and an aggregate object – a CPU and a Monitor are both components of an aggregate object, a PC

VI. Dynamic Modeling: State Diagrams

State – the State of an object depends on the values of its attributes, and is the condition of the object during its life when it satisfies come condition(s), performs some action(s), or waits for some event(s); when the values of its attributes change it undergoes a State Transition

Event – something that takes place at a certain time; an occurrence that triggers a state transition

VII. Dynamic Modeling: Sequence Diagrams

Sequence Diagram – depiction of the interactions among objects during a certain period of time

Activation – the time period during which an object performs an operation

Synchronous Message – message where the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself

Simple Message – message that transfers control from the sender to the recipient without describing the details of the communication

VIII. Designing a Use-Case with a Sequence Diagram

IX. Moving to Design