Object-oriented Analysis And Design

Object-oriented analysis and design From Wikipedia, the free encyclopedia

Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it. Contents [hide]

•

1 Object-oriented systems

•

2 Object-oriented analysis

•

3 Object-oriented design

•

4 Literature

•

5 See also

•

6 References

•

7 External links

[edit]Object-oriented

systems

An object-oriented system is composed of objects. The behavior of the system results from the collaboration of those objects. Collaboration between objects involves them sending messages to each other. Sending a message differs from calling a function in that when a target object receives a message, it itself decides what function to carry out to service that message. The same message may be implemented by many different functions, the one selected depending on the state of the target object. The implementation of "message sending" varies depending on the architecture of the system being modeled, and the location of the objects being communicated with. [edit]Object-oriented

analysis

Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any

implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design (OOD). Analysis is done before the Design[citation needed]. The sources for the analysis can be a written requirements statement, a formal vision document, interviews with stakeholders or other interested parties. A system may be divided into multiple domains, representing different business, technological, or other areas of interest, each of which are analyzed separately. The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one or more UML class diagrams, and a number of interaction diagrams. It may also include some kind of user interface mock-up. The purpose of object oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer defined requirements. [edit]Object-oriented

design

Main article: Object oriented design Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take account of the constraints imposed by the chosen architecture and any non-functional – technological or environmental – constraints, such as transaction throughput, response time, run-time platform, development environment, or programming language. The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model of the solution domain, a detailed description of how the system is to be built.

Class diagram From Wikipedia, the free encyclopedia

Hierarchy of UML 2.0 Diagrams, shown as a class diagram. The individual classes a represented just with one section, but they often contain up to three sections.

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Overview The class diagram is the main building block in object oriented modelling. They are being used both for general conceptual modelling of the systematics of the application, and for detailled modelling translating the models into programming code. The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: [1]

A class with three sections.



The upper part holds the name of the class



The middle part contains the attributes of the class, and



The bottum part gives the methods or operations the class can take or undertake

In the conceptual design of a system a number of classes are identified and grouped together in a class diagram, and further determining the statical relations between those objects. With detailled modelling the classes of the conceptual design are often split in a number of subclasses. In order to further descripe the behavior of systems these class diagrams can be complemented by state diagram or UML state machine. Also instead of class diagrams Object role modeling can be used if you just want model the classes and their relationships.[1]

Sequence diagram From Wikipedia, the free encyclopedia

Simple Restaurant Sequence Diagram

Example of a UML 2 diagram

A sequence diagram in Unified Modelling Language (UML) is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. Sequence diagrams are sometimes called Event-trace diagrams, event scenarios, and timing diagrams.[1] Contents [hide]

•

1 Overview

•

2 Diagram building blocks

•

3 Usage and limitations

•

4 References

•

5 External links

[edit]Overview A sequence diagram shows, as parallel vertical lines ("lifelines"), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. For instance, the UML 1.x diagram on the right describes the sequences of messages of a (simple) Restaurant System. This diagram represents a Patron ordering food and wine, drinking wine then eating the food, and finally paying for the food. The dotted lines extending downwards indicate the timeline, time flows from top to bottom. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls. The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x Sequence Diagram with added support for modeling variations to the standard flow of events. [edit]Diagram

building blocks

If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance name blank can represent anonymous and unnamed instances. In order to display interaction, messages are used. These are horizontal arrows with the message name written above them. Solid arrows with full heads are synchronous calls, solid arrows with stick heads are asynchronous calls and dashed arrows with stick heads are return messages. This definition is true as of UML 2, considerably different from UML 1.x. Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes are being performed in response to the message (ExecutionSpecifications in UML). Objects calling methods on themselves use messages and add new activation boxes on top of any others to indicate a further level of processing. When an object is destroyed (removed from memory), an X is drawn on top of the lifeline, and the dashed line ceases to be drawn below it (this is not the case in the first example though). It should be the result of a message, either from the object itself, or another. A message sent from outside the diagram can be represented by a message originating from a filled-in circle ("found message" in UML) or from a border of sequence diagram ("gate" in UML).

UML 2 has introduced significant improvements to the capabilities of sequence diagrams. Most of these improvements are based on the idea of interaction fragments[2] which represent smaller pieces of an enclosing interaction. Multiple interaction fragments are combined to create a variety of combined fragments[3], which are then used to model interactions that include parallelism, conditional branches, optional interactions etc. [edit]Usage

and limitations The neutrality of this section is disputed. Please see the discussion on the talk page. Please do not remove this message until thedispute is resolved. (September 2009)

Some systems have simple dynamic behavior that can be expressed in terms of specific sequences of messages between a small, fixed number of objects or processes. In such cases sequence diagrams can completely specify the system's behavior. Often, behavior is more complex, e.g. when the set of communicating objects is large or highly variable, when there are many branch points (e.g. exceptions), when there are complex iterations, or synchronization issues such as resource contention. In such cases, sequence diagrams cannot completely describe the system's behavior, but they can specify typical use cases for the system, small details in its behavior, and simplified overviews of its behavior.

State diagram From Wikipedia, the free encyclopedia

A State Diagram for a door that can only be opened and closed

A state diagram is a type of diagram used in computer science and related fields to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. There are many forms of state diagrams, which differ slightly and have different semantics. Contents [hide]

•

1 Overview

•

2 Directed graph

o

2.1 Example: DFA, NFA, GNFA, or Moore machine

o

2.2 Example: Mealy machine

•

3 Harel statechart

•

4 UML state diagram

•

5 State diagrams versus flowcharts

•

6 Other extensions

•

7 See also

•

8 References

•

9 External links

[edit]Overview State diagrams are used to give an abstract description of the behavior of a system. This behavior is analyzed and represented in series of events, that could occur in one or more possible states. Hereby "each diagram usually represents objects of a single class and track the different states of its objects through the system".[1] State diagrams can be used to graphically represent finite state machines. This was introduced by Taylor Booth in his 1967 book "Sequential Machines and Automata Theory". Another possible representation is the State transition table. [edit]Directed

graph

A directed graph.

A classic form of a state diagram for a finite state machine is a directed graph with the following elements:[2][3]



States Q: a finite set of vertices normally represented by circles and labelled with unique

designator symbols or words written inside them;



Input symbols Σ: a finite collection of input symbols or designators;



Output symbols Z: a finite collection of output symbols or designators;

The output function ω represents the mapping of input symbols into output symbols, denoted mathematically as ω : Σ × Q→ Z.



Edges δ: represent the "transitions" between two states as caused by the input (identified by their

symbols drawn on the "edges"). An 'edge' is usually drawn as an arrow directed from the present-state toward the next-state. This mapping describes the state transitions that is to occur on input of a particular symbol. This is written mathematically as δ : Σ × Q → Z



Start state q0: (not shown in the examples below). The start state q0 ∈ Q is usually represented by

an arrow with no origin pointing to the state. In older texts[2][4], the start state is not shown and must be inferred from the text.



Accepting state(s) F: If used, for example for accepting automata, F ∈ Q is the accepting state. It

is usually drawn as a double circle. Sometimes the accept state(s) function as "Final" (halt, trapped) states[3]. For a deterministic finite state machine (DFA), nondeterministic finite state machine (NFA), generalized nondeterministic finite state machine (GNFA), or Moore machine, the input is denoted on each edge. For a Mealy machine, input and output are signified on each edge, separated with a slash "/": "1/0" denotes the state change upon encountering the symbol "1" causing the symbol "0" to be output. For a Moore machine the state's output is usually written inside the state's circle, also separated from the state's designator with a slash "/". There are also variants that combine these two notations. For example, if a state has a number of outputs (e.g. "a= motor counter-clockwise=1, b= caution light inactive=0") the diagram should reflect this : e.g. "q5/1,0" designates state q5 with outputs a=1, b=0. This designator will be written inside the state's circle. [edit]Example:

DFA, NFA, GNFA, or Moore machine

S1 and S2 are states and S1 is an accepting state. Each edge is labeled with the input. This example shows an acceptor for strings over {0,1} that contain an even number of zeros.

[edit]Example:

Mealy machine

S0, S1, and S2 are states. Each edge is labeled with "j / k" where j is the input and k is the output.

[edit]Harel

statechart

Harel statecharts[5] are gaining widespread usage since a variant has become part of the Unified Modeling Language. The diagram type allows the modeling of superstates, orthogonal regions, and activities as part of a state. Classic state diagrams require the creation of distinct nodes for every valid combination of parameters that define the state. This can lead to a very large number of nodes and transitions between nodes for all but the simplest of systems (state and transition explosion). This complexity reduces the readability of the state diagram. With Harel statecharts it is possible to model multiple cross-functional state diagrams within the statechart. Each of these crossfunctional state machines can transition internally without affecting the other state machines in the statechart. The current state of each cross-functional state machine in the statechart defines the state of the system. The Harel statechart is equivalent to a state diagram but it improves the readability of the resulting diagram. [edit]UML

state diagram

Main article: UML state machine

Example UML State diagram.

The UML state diagram is essentially a Harel statechart with standardized notation[6] [7], which can describe many systems, from computer programs to business processes. The following are the basic notational elements that can be used to make up a diagram:

 Filled circle, pointing to the initial state  Hollow circle containing a smaller filled circle, indicating the final state (if any)  Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicated

 Arrow, denoting transition. The name of the event (if any) causing this transition labels the arrow body. A guard expression may be added before a "/" and enclosed in squarebrackets ( eventName[guardExpression] ), denoting that this expression must be true for the transition to take place. If an action is performed during this transition, it is added to the label following a "/" ( eventName[guardExpression]/action ).

 Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively. [edit]State

diagrams versus flowcharts

Newcomers to the state machine formalism often confuse state diagrams with flowcharts. For a long time, the UML specification wasn’t helping in this respect because it used to lump activity graphs in the state machine package (the new UML 2[6] has finally separated activity diagrams from state machines). Activity diagrams are essentially elaborate flowcharts.

The figure below shows a comparison of a state diagram with a flowchart. A state machine (panel (a)) performs actions in response to explicit events. In contrast, the flowchart (panel (b)) does not need explicit events but rather transitions from node to node in its graph automatically upon completion of activities[8].

Graphically, compared to state diagrams, flowcharts reverse the sense of vertices and arcs. In a state diagram, the processing is associated with the arcs (transitions), whereas in a flowchart, it is associated with the vertices. A state machine is idle when it sits in a state waiting for an event to occur. A flowchart is busy executing activities when it sits in a node. The figure above attempts to show that reversal of roles by aligning the arcs of the state diagrams with the processing stages of the flowchart. You can compare a flowchart to an assembly line in manufacturing because the flowchart describes the progression of some task from beginning to end (e.g., transforming source code input into object code output by a compiler). A state machine generally has no notion of such a progression. The door state machine shown at the top of this article, for example, is not in a more advanced stage when it is in the "closed" state, compared to being in the "opened" state; it simply reacts differently to the open/close events. A state in a state machine is an efficient way of specifying a particular behavior, rather than a stage of processing. The distinction between state machines and flowcharts is especially important because these two concepts represent two diametrically opposed programming paradigms: eventdriven programming (state diagrams) and structured programming (flowcharts). You cannot devise effective UML state machines without constantly thinking about the available events. In contrast, events are only a secondary concern (if at all) for flowcharts.

[edit]Other

extensions

An interesting extension is to allow arcs to flow from any number of states to any number of states. This only makes sense if the system is allowed to be in multiple states at once, which implies that an individual state only describes a condition or other partial aspect of the overall, global state. The resulting formalism is known as a Petri net. Another extension allows the integration of flowcharts within Harel statecharts. This extension supports the development of software that is both event driven and workflow driven. [