Information System Analysis
Information System Analysis
Topic 6 ( changed from 5 )
Object-Oriented Analysis & Design
Introduction
l Object-oriented (o-o) techniques work well in situations where complicated systems are undergoing continuous maintenance, adaptation, and design.
l The Unified Modeling Language (UML) is an industry standard for modeling object-oriented systems.
The object-Oriented modeling approach provides several benefits, including:
l Ability to tackle more challenging problem domains.
l Improved communication among users, analysts, designers, and programmers.
l Reusability of analysis, design, and programming results.
l Maintaining systems
l Increased consistency among the models developed during object-oriented analysis, design, and programming
Object- Oriented\ Definitions and concepts
Object:
– An object, represents a real-world thing or event.
– Objects may be customers, items, and so on.
– Objects may be GUI displays or text areas on a display.
– Objects are represented by and grouped into classes.
Object \ Example
Class:
– A class is a group of related objects has a set of shared attributes and behaviors.
§ Attributes are properties of a class possessed by all objects.
§ A method (Operation) is an action that can be requested from any object in the class.
§ Instantiate is a term used when an object is created from a class.
§ Behavior is a manner that represents how an object acts and reacts
Class \ Example
Messages:
Information sent by one object to another
Inheritance:
l Inheritance is when a new class is created from another class.
l The original class is the parent or base class.
l The new class is the child or derived class.
l The child class receives the attributes and methods of the parent class.
Inheritance \ Example
Encapsulation:
l Encapsulation means objects can be accessed only through their interfaces. The caller has no knowledge of variables inside and how the method is implemented. As long as the interfaces are the same, changes to the internal details can be made without changing the code that uses the objects.
l In object-oriented, the technique of hiding the internal implementation details of an object from its external view
l The object is said to "publish its interfaces." Other objects adhere to these interfaces to use the object without having to be concerned with how the object accomplishes it. The idea is "don't tell me how you do it; just do it."
Encapsulation \ Example
Polymorphism:
In object-oriented programming, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class. More specifically, it is the ability to redefine methods for derived classes. For example, given a base class shape, polymorphism enables the programmer to define different area methods for any number of derived classes, such as circles, rectangles and triangles.
Polymorphism \ Example
Unified Modeling Language/ UML
l The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software systems.
Visualizing:
l Explicit model facilitates communication
l Each symbol has well-defined semantics behind it
Visual Modeling:
l VISUAL MODELING is a way of thinking about problems using (graphical) models organized around real-world idea.
l UML is a product of VISUAL MODELING language.
Specifying:
l UML addresses the specification of all important analysis, design, and implementation decisions.
Constructing:
l Forward engineering: generation of code from model into programming language
l Reverse engineering: reconstructing model from implementation
Round-trip engineering: going both ways
Documenting:
l Deliverables, such as requirements documents, functional specifications, and test plans
l Materials that are critical in controlling, measuring, and communicating about a system during development and after deployment
Models are useful for:
l understanding problems,
l communicating with everyone involved with project (customer, analysts, designers, etc.)
l preparing documentation
l designing programs and databases
What is a good Model?
l it is a relevant model
l it is possible to communicate
l it fits its purpose
l it captures the essentials
What does UML give you?
l The UML gives you a standard way to write a system’s blueprints covering conceptual things, such as business processes and system functions, classes written in a specific programming language, database schemas, and reusable software components.
Note:
l UML is phase independent and it is a modeling language (NOT a method)
UML Diagrams:
– Structural Type Diagrams (Static Representations)
l Class Diagrams
– Behavioral Type Diagrams (Dynamic Representations)
l Activity Diagrams
l Use Case Diagrams
l Sequence Diagrams
Activity Diagram:
l The easiest way to visualize an Activity diagram is to think of a flowchart of a code.
l Activity diagrams represent the business and operational workflows of a system
l An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state.
How to Draw Activity Diagram:
• Activity diagrams show the flow of activities through the system
• Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities.
• A fork is used when multiple activities are occurring at the same time.
• The branch describes what activities will take place based on a set of conditions
• All branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch.
• After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state
Activity diagram \ Example 1: Manage course information
Activity diagram \ Example 2 : Ordering
Activity diagram \ Example 3 :
Prepare Beverage
Use Case Diagram:
l UML Use Case Diagrams can be used to describe the functionality of a system.
l Use case diagram is done in the early stages of system development (during the analysis phase) to help developers understand the functional requirements of the system without worrying about how those requirements will be implemented.
Use Case Diagram have the following Elements:
1. Actor:
§ Is an external entity that interact with the system (similar to EE in DFD).
§ It is someone or something that exchanges information with the system.
§ An actor is a role that a user plays in the system
§ What is the Different between Actor & User?
§ A user of the system may play several different roles through the course of his, her or its job (since an actor may be another system).
§ Examples of actors are salesperson, manager, support person, and web store system. It is possible that the same person may be a sales person and also provide support.
2. Use Case:
l Represents a sequence of related actions initiated by an actors, it’s a specific way of using the system
l A use case is a set of scenarios that describing an interaction between a user and a system.
l A use case diagram displays the relationship among actors and use cases.
Use Case: Example
l Print Invoice
l Correct Invoice
l Chase Payment
l Register Bad Debt
Actors and Use Cases:
l An Actor may use many Use Cases
l A Use Case may interface with many Actors
l We draw a simple line to indicate interaction
Relationships between actors and use cases:
The direction of the arrow indicates who initiates the interaction.
Sometimes the use case initiates interaction
3. Relationship between Use cases:
l One Use Case may use another Use Case
l Sometimes a Use Case gets too big to manage sensibly and it makes sense to break this down into smaller Use Cases.
There are two ways Use Cases can relate:
A. Use Cases include other Use Cases
In this case the second Use Case is always invoked as part of the execution of the first.
B. Use Cases extend other Use Cases
A Use Case is only called occasionally from another Use Case
Use Case Diagram / Guidelines:
l Use Case Names Begin With a Strong Verb
l Name Use Cases Using Domain Terminology
l Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
l Imply Timing Considerations By Stacking Use Cases.
Use Case Diagram / Example 1:
Example 2
Example 3
Example 4
Class Diagram
l A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them.
– A graphical representation of a static view on static elements
Elements of a Class Diagram:
l Class
l Attributes
l Operations
l Relationships
l A class is the description of a set of objects having similar attributes, operations, relationships and behavior.
l An object is any person, place, thing, concept, event, screen, or report applicable to your system.
l Objects both know things (they have attributes) and they do things (they have methods)
l Relationships:
1. Associations:
§ A semantic relationship between two or more classes that specifies connections among their instances.
§ A structural relationship, specifying that objects of one class are connected to objects of a second (possibly the same) class.
§ Example: “An Employee works in a department of a Company”
l Multiplicity:
An indication of how many objects participate in a given relation ship
Indicator / Meaning0..1 / Zero or one (one is optional)
1 / One only (Mandatory)
0..* / Zero or more (more means many and its optional)
1..* / One or more
n / Only n (where n>1)
0..n / 0 to n (n>1)
1..n / 1 to n (n>1)
2. Aggregation
l A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.
l Aggregation is a specialization of association, specifying a whole-part relationship between two objects.
l employee is part of a team
l An engine is part of a plane
3. Inheritance
l Generalization
l Specialization
Sequence Diagram
l Definition: Is an interaction diagram that emphasizes the time ordering of messages for a specific use case.
l A sequence diagram: is a graphical view of a scenario that shows object interaction in a time-based sequence-what happens first, what happens next.
l What is a UML Sequence Diagram?
Diagram used to graphically show the interaction between objects over time.
l Graphically, it is a 2-dimensional table that shows objects arranged along the X-axis and messages, ordered in increasing time, along the Y-axis.
l Sequence diagrams have two dimensions:
§ Horizontal :Represents different objects
§ Vertical : Represents time
sequence diagrams parts:
1. Actor
· Actors can also communicate with objects, so they too can be listed as a column. An Actor is modeled using the stick figure.
· person (or role) that “interacts” with a system by entering input data and receiving output data
2. Object
· Objects are instances of classes, and are arranged horizontally. The pictorial representation for an Object is a class (a rectangle) with the name prefixed by the object name (optional) and a semi-colon.
3. Lifeline
· Lifeline
– Shows the time of existence of the object – from creation to deletion
· Activation/Control focus
– Shows the time period during which the object performs an operation
4. Message
· Objects interact with one another using messages
· Messages, modeled as horizontal arrows between Activations, indicate the communications between objects.
Types of Message:
1. Simple or sequential:
• Caller waits for receiving object to finish processing.
• It’s bi-directional “one-way message” but it may include a response.
• It’s represented by an ordinary arrow.
2. Response (Return):
• Shows the objects response of the other objects simple message.
• Represented by a dashed-line arrow.
Creating a Sequence diagram\Guidelines:-
l Select Use-case and Scenario
l Using Scenario
1. Identify Actors
2. Identify Objects
§ Look for nouns
§ Already identified in the Class diagram
3. Identify initiating actor
4. Add objects and lifeline to diagram
5. Create a controller object
§ A point of contact created to coordinate the actor’s interaction with the rest of the system
§ Provides an interface between the actor and the internal system
§ They are invented objects who mangers other objects
§ Eg: ATM, GUI window
§ Usually created (not always necessary)
6. Discover Messages
§ Look for verbs
§ Identify the source and destination of the message;
7. Add messages to diagram
Sequence diagram\Example (cellular phone):-
- Consider your cell phone .when you dial a number you normally pick the person you want to call, the phones software search’s the number in your phonebook, displays it on your screen & sends the request of calling to the company. so….
After analyzing the case:
– Actors needed :
l You “ The owner ”: The one who’s dialing or requesting the call.
l The company : who receives the call to divert it to the requested person.
– The objects are:
– The keypad “ the one used to insert the selection”
– The phone’s software, or let us call it “controller” : searches the number, displays it & sends the request.
– Phone book “ where the numbers are kept”
– Screen “ displays the number”
Notes
1. When you dial a number, You first select the name using the keypad. So a message is sent from the actor ”you” to the keypad object.
2. When you dial a number, You first select the name using the keypad. So a message is sent from the actor ”you” to the keypad object.
3. The number is searched and retrieved to the controller.
q Two messages are sent:
§ The one from the controller to the phonebook
§ Then from the phonebook back to the controller