Object-Oriented (O-O) Analysis - System Development Method: Object Modeling

Views the system in terms of objects that combine data and process. Whereas Structured Analysis treats processes and data as separate components, object-oriented analysis combines data and processes that act on the data into things called objects. The objects represent actual people, things, transactions, and events. Compared to structured analysis, object-oriented phases tend to be more interactive. Some of the advantages that object oriented analysis offers are that it integrates easily with object oriented programming languages such as Java, Small talk, C++, and Perl. Programmers also like O-O code because it is modular, reusable, and easy to maintain. In other words, a major advantage of O-O designs is that systems analyst can save time and avoid errors by using modular objects, and programmers can translate the designs into code, working with reusable program modules that have been tested and verified.

Structured Analysis or Object Oriented first?

In structured analysis, data and processes are treated separately, so you will learn them separately instead of starting out in object oriented analysis where they are combined. Object oriented includes data and the processes that affect that data. This means that object oriented techniques treat data and processes together. If you were to learn object oriented technique first, before structured analysis, I think it would be more frustrating when moving to structured analysis after objects because you would then have to get used to treating data and processes separately after you just learned that they are used together! This is another reason why I think you should learn structured analysis first. Once you finish learning structured analysis, object oriented technique will seem easier because you will have already understood how data and processes are used and how they relate to each other. This should make object oriented technique flow a little smoother and seem easier without having to learn additionally how data and processes flow. Even though object oriented diagrams include stick figures (actors), generally when customers look at structured analysis (DFDs) vs. Object Oriented diagrams, customers seem to understand the structured analysis better, because it shows all the data flowing with arrows indicating the direction of data flow

Encapsulation

All data and methods are self contained. A black box concept is an example of encapsulation. Encapsulation allows objects to be used as modular components anywhere in the system, because objects send and receive messages but do not alter the internal methods of other objects.

Black Box

You can view an object as a black box, because a message to the object triggers changes within the object without specifying how the changes must be carried out. Example, a gas pump is like a black box. When you select the economy grade at a pump, you do not need to think about how the pump determines the correct price and selects the right fuel, as long as it does it properly. The black box concept is an example of encapsulation. A black box does not want or need outside reference. A black box, like encapsulation, is an important concept in object oriented analysis because the black box is limiting access to internal processes; an object prevents its internal code from being altered by another object or process. The black box concept allows you to view the system or other parts of the system without having to view other processes or objects.

Polymorphism

The same message to two different objects can produce different results. The concept that a message gives different meanings to different objects is called polymorphism. Example, the message GOOD NIGHT signals the PARENT object to read a bedtime story, but the same message to the DOG object tells the dog to sleep. The GOOD NIGHT message to the CHILD object signals it to get ready for bed. In simple terms, polymorphism means that a message can mean two different meanings when the parent and child objects are compared for the same message.

Actor - Object

Actor - an external entity with a specific role. In a use case model, actors are used to model interaction with the system. An external entity called an actor initiates a use case by requesting the system to perform a function or process. Example, in a medical office system, a PATIENT (actor) can MAKE APPOINTMENT (use case). - (Actor - also see use-case below)

Use Case / Use Case Diagram

A use case represents the steps in a specific business function or process. A use case involves actors, descriptions, and an oval UML symbol with a label that describes the action or event. The actor is shown as a stick figure, with a label that identifies the actor's role. The line from the actor to the use case is called an association, because it links a particular actor to a use case. A use case diagram is a visual summary of several related use cases within a system or subsystem. The use case diagram identifies the system boundaries which are represented by a rectangle. The system boundary shows what is included in the system (inside the rectangle) and what is not included in the system (outside the rectangle). Example, consider a typical auto service department. The service department involves customers, service writers who prepare work orders and invoices, and mechanics who perform the work. Another example, an airline company involves customers, ticket salespersons who prepare an itinerary and invoice.

Use Case Diagram

Diagram Objects:

Relationships

Inheritance

Child-Parent

Use Case Modeling:

Case

Use Case

Class Diagrams

Sequence Diagrams

State Transition Diagrams

Activity Diagrams

Symbols (Objects):

Actor (External entity)

Arrow association

Stick Figures

System Boundary

UML
(Unified Modeling Language):

Characteristics (Properties)

Attributes

Methods

Messages

Polymorphism

Encapsulation (Black Box)

Super class

Class

Subclass

Instance

Use Case Diagram
Inner rectangle: System Boundary

Back to Main