OBJECT ORIENTED ANALYSIS & DESIGN_UNIT-1 [NOTES]
1.4 What is Object-oriented Analysis and Design?
During object-oriented analysis there is an emphasis on finding and describing the objects-or concepts-in the problem domain. For example, in the case of the flight information system, some of the concepts include plane, Flight, and Pilot.
During object-oriented design there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, a plane software object may have a tailNumber attribute and a getFlightHistory
They are four steps
1.Define use case diagram
2.Define a Domain Model
3. Draw Interaction Diagrams
4. Define Design class Diagrams
Define use case diagram:
Requirements analysis may include stories or scenarios of how people use the application. These can be written as use cases.
Use cases are not an object-oriented artifact-they are simply written stories. However, they are a popular tool in requirements analysis. For example, Here is a brief version of the play a Dice Game use case:
Play a Dice Game: Player requests to roll the dice. System presents results. If the dice face value totals seven, player wins; otherwise, player loses.
2. Define a Domain Model
Object-oriented analysis is concerned with creating a description of the domain from these perspectives of objects. There is an identification of the concepts, attributes, and associations that are considered noteworthy.
The result can be expressed in a domain model that shows the noteworthy domain concepts or objects.
This model illustrates the noteworthy concepts Player, Die, and DiceGame, with their associations and attributes.
Notes that a domain model is not a description of software objects; it is a visual-ization of the concepts or mental models of a real-world domain. Thus it has also been called a conceptual object model.
3. Draw Interaction Diagrams:
Object-oriented design is concerned with defining software objects-their responsibilities and collaborations. A common notation to illustrate these collaborations is the sequence diagram. It shows the flow of messages between software objects, and thus the invocation of methods.
For example, The sequence diagram in illustrates an OO software design, by sending message to instances of the Dice Game and Die Classes.
NOTE: This illustrates a common real-world way the UML is applied: by sketching on a whiteboard.
Notice that although in the real world a player rolls the dice, in the software design the dice game object “rolls” the Dice. Software object design and programs do take some inspiration from real-world domains. But they are not direct models or simulations of the real world.
4. Define Design class Diagrams:
In addition to a dynamic view of collaborating objects in interaction diagrams, a static view of the class definitions is usefully shown with a design class diagram. This illustrates the attributes and methods of the classes.
For example: In the dice game, an inspection of the sequence diagram leads to the partial design class diagram show in fig 1.5 since a play message is sent to a dice Game object, the Dice Game class requires a play method, while class die requires a roll and getFaceValue method.
The dice game is a simple problem, presented to focus on a few steps and artifacts in analysis and design. To keep the introduction simple, not all the illustrated UML notation was explained, future chapters explore analysis and design and these artifacts in closer detail.
1.5 What is the UML?
The Unified Modeling Language visual language for specifying, constructing and documenting the artifacts of systems
The word visual in the definition is a key point-the UML is the de facto standard diagramming notation for drawing or presenting pictures (with some text) related to software-primary OO software.
Three ways to Apply UML:
§ UML as sketch-Information and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space, exploiting the power of visual language.
§ UML as blueprint-Relatively detailed diagrams used either for 1 reverse engineering to visualize and better understanding exiting code in UML diagram, or for 2 code generation (forward engineering).
§ UML as programming language-Complete executable specification of a software system in UML executable code will be automatically generated, but is not normally seen or modified by developers; one works only in the UML “Programming language” This use of UML requires a practical way to diagram all behavior or logic
Three Perspectives to Apply UML
The UML describe raw diagram type, such as class diagram and sequence diagram, it does not superimpose a modeling perspective on these. For example, the same UML class diagram notation can be used to draw pictures of concepts in the real world or software classes in Java.
1. Conceptual perspective-The diagram are interpreted as describing things in a situation of the real world or domain of interest
2. Specification (software) perspective-the diagram (using the same notation as in the conceptual perspective) describe software abstractions or components with specifications and interfaces, but no commitment to a particular implementation (for example, not specification a class in C# or Java).
3. Implementation (software) perspective- The diagram describes software implementations in a particular technology (such as Java).
The same UML class diagram notation is used to visualize a domain model and a design model.
1.7 Visual modeling is good thing
At the risk of the blindingly obvious drawing or reading UML implies.