Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Object-Oriented Analysis and Design

No description

Margarita Fonte

on 30 December 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Object-Oriented Analysis and Design

Analysis and Design Presented by:
BAAFFS Object-Oriented Model -has an ability to thoroughly represent complex relationships; represent data with a consistent notation. analysis phase consists of progressively developing an object representation through three phases design phase implementation phase The Unified Modeling Language (UML) UML Graphical Diagrams Object Modelling: Class Diagram State Diagram State - Condition during life of an object during which it satisfies some condition(s); performs some action(s); waits for some event.

- The state changes when the object receives some event; the object is said to undergo a state transition.

- The state of an object depends on its attribute values and links to other objects. Process Modeling : Activity Diagrams Activity Diagram - shows the conditional logic for the sequence of the system activities needed to accomplish a business process.

- another view or model of a system, which combines aspects of both sequence and state diagrams, and is similar to a data diagram from the structured methodology Other Type of Diagrams What are Packages? Component Diagram Deployment Diagram – shows the software components or modules and their dependencies. – shows how the software components, processes, and objects are deployed into the physical architecture of the system. It shows the configuration of the hardware units and how the software is distributed across the units. Object-Oriented Development Life Cycle and It abstracts concepts from the application domain and describes what the system must do rather than how it will be done. It is much easier and cheaper to make changes or fix flaws during analysis than during the later phases. define as how the application-oriented analysis model will be realized in the implementation environment. implementing the design using a programming language and/or a database management system. Three Reasons for using Object-Oriented Design •The analysis model is not formal enough to be implemented directly in a programming language. •The actual system must be adapted to the environment in which the system will actually be implemented. To accomplish that, the analysis model has to be transformed into a design model. •The analysis results can be validated using object-oriented design. - you must identify and investigate the consequences
that the implementation environment will have on the design. - you incorporate those decisions into a first-cut
design model that adapts to the implementation environment. Steps
to Develop
the Design Model - you formalize the design model to describe model to describe how the objects interact with one environment. Two Stages of Design Activity System Design Object Design propose an overall system architecture, which organizes the system into components called subsystems and provides the context to decisions. build a design model by adding implementation details to the analysis model in accordance with the strategy established during system design. is a language for specifying, visualizing, and constructing the artifacts of software systems, as well as for business modeling. allows you to represent multiple views of a system using a variety of graphical diagrams such as use-case diagram class diagram state diagram sequence diagram collaboration diagram and UML notation useful for graphically depicting object-oriented analysis and design models. It allows you to specify the requirements of a system and capture the design decisions and promotes communication among key persons involved in the development effort. Use-Case Modeling •Pioneered by for analyzing the functional requirements of a system. Jacobson •Focuses on what an existing system does or a new system should do. •Done in the early stages of systems development to help developers gain a clear understanding of the functional requirements of the system, without worrying about how those requirements will be implemented. •Process is inherently iterative developers need to involve the users in discussions throughout the model development process and finally come to an agreement on the requirements specification. •Use-Case-Driven Design use-cases control the formation of all other models, promotes traceability among the different models. •Use-Case model consists of actors and use case an external entity that interacts with the system a complete sequence of related actions initiated by an actor to accomplish a specific goal someone that exchanges information with the system it represents a specific way of using the system Difference between User and Actor User is anyone who uses the system is a specific instance of an actor class playing the actor’s role Actor while represents a role that a user can play is a type or class of users developed in the analysis phase of the object-oriented system development life cycle Use-Case Diagram a diagram that depicts
the use cases and actors for a system
•An actor does not necessarily have to be a human user. It could be anything which the system interacts or exchanges information. Note: •A use case is always initiated by an actor; it can interact with actors other than the one that initiated it. •A use case represents a complete functionality. You should not represent an individual action that is part of an overall function as a use case. Use cases help you to capture the functional requirements of a system. Relationships Between Use Cases Two types of relationships: 1. Extend Relationship shown as a dashed line arrow pointing toward the extended use case and labeled with the <<extend>> symbol, extends a use case by adding new behavior or actions. 2. Include Relationship arises when one use case references another use case. It is also shown diagrammatically as dashed line arrow pointing toward the use case that is being used; the line is labeled with the <<include>> symbol. •Employ extend, if the intent is to model an extension to, or a variation of, a complete use case that exists in its own right. •Employ include, if the intent is to factor the common behavior among two or more use cases into a single generalized use case. an invaluable vehicle for communication between developers and end users promotes modifiability, by allowing you to easily trace the effects of changes you make in the use-case model on other models it should focus on its external behavior, that is, how it interacts with the actors, rather than how the use case is performed inside the system •Basic Course – which is always performed – independent of whether the extension is performed or not.
•Alternative Course – This is performed only under special circumstances.
•Abstract Use Case – a use case which is never performed by itself. Dynamic Modeling: Sequence Diagrams 2 Types of Interaction Diagrams Sequence Diagrams show explicit sequencing of message Collaboration Diagrams show relationship among objects Components of a Sequence Diagram depicts the interactions among objects during a certain period of time (only the interactions pertinent to a specific use case) - presented either in a: - shows all possible sequences of interactions(sequences corresponding to all scenarios of a use case) Generic Form Instance Form - shows the sequence for only one scenario - represented as vertical dashed line, represents the object’s existence over a certain period of time. Lifeline - a box with the object’s name underlined, is placed at the head of each lifeline. Object Symbol - represented by a thin rectangle, shows the time period during which the object performs an operation, either directly or through a call to some subordinate operation. Activation - represented as a solid arrow, could be of different types. Message an invaluable tool for specifying and understanding the flow of control it help you to effectively and easily capture the dynamic aspects of the system by implementing the operations, messages and the sequencing of those messages in the target programming language. When coding the system, 1.Registration Clerk opens the registration and enters the registration information (student and class).

2.Check if the class is open.

3.If the class is open, check if the course has many prerequisites.

4.If the course has prerequisites, then check if the student has taken all of those prerequisites.

5.If the student has taken those prerequisites, then register the student for the class, and increment the class by one.

6.Check if the class is full; if not, do nothing.

7.Display the confirmed registration in the registration window. Designing a Use Case with a Sequence Diagram (Class Registration) Example: - Synchronous Message Types of Message caller has to wait for the receiving object to complete executing an operation before it can resume execution. (CheckIfOpen).
always has an associated return message (some return value/s or simply acknowledge that the operation is successfully completed). transfers control from the sender to the recipient without describing details of communication. - Simple Message - Asynchronous Message the sender does not have to wait for the recipient to handle the message. The sender can continue executing immediately after sending the message. - are specifications that preserve the integrity of the logical data model. 1. Each instance of an entity type must have a unique identifier that is not null.
2. Rules concerning
the relationships between entity types. Four Basic Types of Business Rules: 3. Constraints on valid values for attributes.
4. Other business rules that protect the validity of attribute values. Entity integrity. Referential integrity constraints. Domains. Triggering operations. BUSINESS RULES DYNAMIC MODELING: STATE DIAGRAM - Changes in the attributes of an object or in the links an object has with other objects.
State Transition
- Something that takes place at a certain point in time.
- It is a noteworthy occurrence that triggers a state transition.
Event - A state diagram captures the states of a single class of objects.

- To develop a dynamic model for an application you need to combine all the state diagrams you have to drawn for different object classes.

- In such a model, the interaction among the component state diagrams are shown via shared events.

- In UML, a state is shown as a rectangle with a rounded corner, initial state is shown as a small solid filled circle, transition is shown as a solid arrow, and the final state is shown as a bull’s eye: a small solid filled circle surrounded by another circle.
State Transition Diagramming Figure 20-20 State Diagram for Student Object Figure a20-21
Nested State Diagram for the Accepts Admission Offer Event Figure 20-22
Nested State Diagram for
the Accepts Admission Offer Event Each column – swimlane
Vertical axis – time
Large dot ( ) – start of process
Rounded Rectangles ( ) – activities
Fork ( )
Join ( )
Branch ( )
Merge ( )
End ( ) Analysis VS. Design Which diagrams belong to the Analysis Phase and which diagrams belong to the Design Phase? - consists of group of classes.

- classes wuthin a package are cohesive, that is, they are tightly coupled.

- the packages themselves should be loosely coupled so that changes in one package do not affect the other packages a great deal. - are set of cohesive, tightly coupled classes representing a subsystem. Typical Activities during Design
by Eriksson and Penker (1998) Designing the architecture of the system in terms of functional packages, such as those for user interface, database storage and retrieval, and communication.

Designing user interfaces.

Mapping the classes to constructs in the chosen DBMS for storage and retrieval.

Allocation of classes to source code and executable code components. Modeling concurrent processes by using active classes, multiple threads of control, asynchronous messages, and so forth. Identifying class libraries and components that could be reused. Designing mechanisms for handling faults and errors. That's all! Thank You for Listening!!! ^_^ Object an entity that has well-defined role in the application domain, and has state, behavior and identity. An object is a concept, abstraction or thing that makes sense in an application context. Object can be: - – e.g. Person, Place or Thing
- – e.g. Department, Performance, Marriage, Registration
- – e.g. User Interface, Controller, Scheduler Object has a state and behavior, through operations that can examine or affect its state. - – encompasses an object’s properties (attributes and relationships) and the values those properties have. Determined by attribute values and links to other objects.
- – represents how an object acts and reacts. Depends on its state and the operation being performed.
- – simply an action that one object performs upon another in order to get a response. Tangible or Visible Entity Concept or Event Artifact of Design Process Operation Behavior State -All objects have an identity; that is, no two objects are the same.

-The term “object” is sometimes used to refer to a group of objects, rather than an individual object.

-Object refers to an individual object, not to a class of objects. In order to eliminate any possible confusion altogether, we can use the object instance and object class.

Object Instance – refer to an individual object.

Object Class – refer to a set of objects that share a common structure and a common behavior.
Notes: - shows the static structure if an object-oriented model: the object classes, their internal structure, and the relationships in which they participate. Class Diagram Object Diagram – also known as “Instance Diagram”, is a graph of instances that are compatible with a given class diagram. Object is represented as a rectangle with two compartments.
Names of the object and its class are underlined and show in top compartment using the following syntax: objectname : classname
The object’s attributes and their values are shown in second compartment.
Values of not interest may be suppressed.
Name of the object may be omitted but colon should be kept in class name.

CONSTRUCTOR OPERATION – an operation that creates new instance.

QUERY OPERATION – an operation that accesses the state of an object but does not alter the state.

UPDATE OPERATION – an operation that alters the state of an object.

SCOPE OPERATION – an operation that applies to a class rather than an object instance. function or a service that is provided by all instances in the class. E.g is the calc-gpa in Student (Figure 1.a). Operation Encapsulation the technique of hiding the internal
implementation details of an object from its external view. Types of Operation Representing Associations - a relationship among instances of object classes.
- degree may be one (unary), two (binary), three (ternary) or higher (n-ary) Association - the end of an association where it connects to a class.
- each association has two or more roles. Association Role Each role has a multiplicity.

indicates how many objects participate in a given relationship Representing Association Classes - Association Class "An association that has attributes or operations of its own, or that participates in relationships with other classes." A derived attribute, association or role is one that can be computed or derived from other attributes, associations and roles respectively. A derived element (attribute, association or role) is shown by placing slash (/) before the name of the element. Representing Derived Attributes,
Derived Associations and Derived Roles Representing Generalization abstraction of the common features (attributes and operations) among multiple classes, as well as the relationships they participate in, into a more general class. "classes that are generalized" - Subclasses - Superclass "class they are generalized into" class that has no direct instances, but whose descendants may have direct instances. Abstract Class Concrete Class a class that can have direct instances. OVERLAPPING – a descendant may be descended from more than one of the subclasses.

DISJOINT – a descendant may not be descended from more than one of the subclasses.

COMPLETE – all subclasses have been specified (whether or not shown). No additional subclasses are expected.

INCOMPLETE – some subclasses have been specified, but the list is known to be incomplete. There are additional subclasses that are not yet in the model. Definition of Terms: an attribute of a class which specifies a value common to an entire class, rather than specific value for an instance. Class-Scope Attribute defines the form or protocol of the operation, but not its implementation. Abstract Operation Method Polymorphism the implementation of an operation.
the same operation may apply
to two or more classes in different ways. Interpreting Inheritance and Overriding Representing Multiple Inheritance Representing Aggregation - an object is an instance of more than one class. Multiple Classification – the process of replacing a method inherited from superclass by a more specific implementation of that method in a subclass. Overriding – an operation inherited by a subclass from its superclass is extended by adding some behavior (code). Overriding for Extension Overriding for
Restriction Overriding for Optimization – the new operation is implemented with improved
code by exploiting the restrictions imposed by a subclass. – the protocol of the new operation in the subclass is restricted. - a part-of relationship between a component object and an aggregate object.
- represented with a hollow diamond at the aggregate end
- A solid diamond represents a stronger form of aggregation, known as composition. Aggregation - a part object belongs to only one whole object, and that lives and dies with the whole. Composition illustrates messages being sent between classes and objects (instances). created for each system operation that relates to the current development cycle (iteration). patterns are used to justify relationships - are best principles for assigning responsibilities to objects evaluative patterns and driving patterns. Two Main Types of Patterns show the sequence by numbering the messages on the diagram. use-cases control the formation of all other models, promotes traceability among the different models.
Full transcript