object oriented modeling and design
Post on 24-Nov-2015
21 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
What is Analysis?
Analysis emphasizes an investigation of the problem and requirements, rather than a
solution.
For example: - In an online trading system, we analyze
How will it be used?
What is its function?
Requirement analysis An investigation of the requirements
Object oriented analysis An investigation of the domain objects.
In object oriented analysis there is an
emphasis on finding and describing
the objects or concepts in the problem
domain
What is Design?
Design emphasizes a conceptual solution that fulfills the requirements rather than its
implementation.
For example: - description of database schema and software objects.
In object oriented design there is an emphasis on defining s/w objects and how they
collaborate to fulfill the requirements.
Basic terms in OOAD
1. Use case
Use case includes stories or scenarios of how people use the application. It's a popular
tool in requirements analysis.
-
Example: -
Play a Dice Game use case
Player requests to roll the dice. System presents results. If the dice face value totals
seven, player wins; otherwise, player loses.
2. Domain Model
Domain model is a visualization of the concepts (or mental objects) of a real world
domain. It is also called conceptual object model.
3. Sequence Diagram
A sequence diagram shows the flow of messages between software objects, and thus the
invocation of methods. It provides a dynamic view of collaborating objects. It is a kind
of UML interaction diagram.
-
4. Design class diagram
Design class diagram shows a static view of the class definitions. It shows software
classes. It illustrates the attributes and methods of the classes.
What is Artifact?
Tangible byproduct produced during the development of software. Example: Use case
diagrams, Class diagrams.
What is UML?
UML is a visual language for specifying, constructing and documenting the artifacts of
the systems. It is the de-facto standard diagramming notation for drawing or presenting
pictures related to software, especially object oriented software.
Three ways to apply to UML
UML as sketch: - Informal and incomplete diagrams often hand sketched on
whiteboards. Agile modeling emphasize UML as sketch.
UML as blueprint: - Relatively detailed designed diagram used either for reverse
engineering or for code generation.
UML as programming language: - Complete executable specification of a software
system in UML.
-
Three perspectives to apply UML
1. Conceptual perspective: -The diagrams describe things in a situation of the real world or domain of interest.
2. Specification perspective: -The diagrams describe software abstractions or components with specifications and interfaces, but no commitment to a particular
implementation.
3. Implementation perspective: -The diagrams describe software implementations in a particular technology(such as Java)
Types of classes
1. Conceptual class:- Class representing a real world concept or thing 2. Software class: - Class representing a specification or implementation
perspective of a software component.
3. Implementation class: - A class implemented in a specific OO language.
What is software development process?
It describes an approach to building deploying and possibly maintaining software.
Examples: Unified Process (UP), Extreme Programming (XP), Scrum
-
What is Unified Process (UP)?
The Unified Process is a popular iterative software development process for building
object oriented systems.
UP is very flexible, open and encourages including skillful practices from other iterative
methods into it. For example, the practices like test driven development, re-factoring and
continuous integration of Extreme Programming (XP).It also include the practice of
scrum such as common project room and daily meeting practice.
What is Iterative and Evolutionary Development?
In this life cycle approach, the development is organized into a series of short, fixed-
length mini projects called iterations. The outcome of each iteration is tested, integrated
and executed. Each iteration includes its own requirements analysis, design, and
implementation and testing activities. The iterative lifecycle is based on the successive
enlargement and refinement of the system through multiple iterations with cyclic
feedback and adaptation as core drivers. The system grows incrementally over time,
iteration by iteration. Thus this approach is also known as iterative and incremental
development. Since the feedback and adaptation evolve the specifications and design, it
is also known as iterative and evolutionary development.
Changes in iterative development
Unlike Waterfall model, changes reflect in the system quickly because of feedback and
adaptation. Each iteration involves choosing a small subset of requirements, quick
design, implementation and testing. The changes appear in the developed system gives a
clear idea to the user about the system they really needs. Since it is a series of structured
build-feedback-adapt cycles, the deviation from the actual path will be less in the later
iterations compared to early ones.
Benefits of Iterative development
1. Less project failure, better productivity and lower defect rates.
2. Early rather than late mitigation of high risks.
3. Early visible progress.
4. Early feedback, user engagement and adaptation.
5. Manage complexity.
6. Improves the development process.
-
Length of iterations
Most iterative methods recommend iteration length between 2 to 6 weeks. Small steps,
rapid feedback and adaptation are the central ideas in iterative development. Long
iterations increases the project risk. A very long time boxed iterations misses the point of
iterative development. Short is good.
Waterfall life cycle
Waterfall life cycle defines all or most of the requirement before programming. It creates
a thorough design before programming.
Reasons for failure of waterfall
A study on typical software project has showed that the software development is a
domain of high change and instability. Thus waterfall life cycle which is based on the
assumption that things are long term stable is fundamentally flawed.
-
Types of Iterative planning
Risk-driven: -Identify and drive down the highest risks.
Client-driven: -Build visible features that the client cares most about.
Agile development methods
Agile development methods usually apply timeboxed iterative and evolutionary
development ,employ adaptive planning, promote incremental delivery and include other
values practices that encourage agility(rapid and flexible response to change).
Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
-
The Agile Principles
1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Always welcome change in the requirements even late in the development.
3. Deliver working software frequently.
4. Business people and developers work together daily throughout the project.
5. Build projects around motivated individuals.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
9. The sponsors, developers and the users should be able to maintain a constant pace.
10. Continuous attention to technical excellence and good design enhances agility.
11. Simplicity the art of maximizing the amount of work not done.
12. The best architectures, requirements and designs emerge from self-organizing teams.
13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Modeling
Agile modeling implies the following practices and values: -
Adopting an agile method does not mean avoiding any modeling.
The purpose of modeling and models is primarily to support understanding and communication, not documentation.
Model and apply the UML for the smaller percentage of unusual, difficult, tricky parts of the design space.
Use the simplest tool possible
Dont model alone, model in pairs or triads.
Create models in parallel.
-
Use simple notation while sketching with a pen on whiteboards.
Remember, all models will be inaccurate, and the final code or design differs from the model.
Developers should do the OO design modeling.
Agile UP
Agile Unified Process is a simplified version of the Unified Process. It describes a simple, easy to understand approach to developing business application software
using agile techniques and concepts. The approach applies agile techniques
include test driven development (TDD), Agile Model Driven Development
(AMDD), agile change management, and database refactoring to improve the
productivity.
Agile UP prefers small set of UP activities and artifacts.
Focus on early programming. Not in early documentation.
Apply UML with Agile modeling practices.
In Agile UP, there is no detailed plan for the entire project. Only one iteration in advance is planned (called Iteration Plan). Detailed planning is done adaptively
from iteration to iteration.
Unified Process Phases
A UP project organizes the work and iterations across four major phases: -
1. Inception: - approximate vision, business case, scope, vague estimates.
2. Elaboration: - refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more
realistic estimates.
3. Construction: - iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
4. Transition: - beta test, deployment.
-
UP Disciplines
A set of activities and related artifacts in one subject area, such as the activities within
requirements analysis. In the UP an artifact is the general term for work product: code,
Web graphics, database schema, text document, diagrams, models and so on. There are
several disciplines in UP. Some of them are: -
Business modeling: - The domain model artifact to visualize noteworthy concept in the application domain.
Requirements: - The Use-Case model and Supplementary Specification artifacts to capture functional and non-functional requirements.
Design: - The Design Model artifact, to design the software objects.
-
Inception
Inception is initial short step to establish a common vision and basic scope for the
project. The purpose of the inception phase is not to define all the requirement or
generate a believable estimate or project plan. Some of the questions asked during the
inception phase are:
What is the vision and the business case for this project?
Feasible?
Buy and/or build?
Rough unreliable range of cost.
Should we proceed or stop.
Requirements
Requirements are capabilities and conditions to which the system or the project must
conform.
A prime challenge of requirements analysis is to find, communicate and remember what
-
is really needed, in a form that clearly speaks to the client and development team
members.
Types and Categories of Requirements
Based on FURPS+ model: -
Functional features, capabilities, security.
Usability human factors, help, documentation
Reliability frequency of failure, recoverability, predictability
Performance response times, throughput, accuracy, availability, resource usage
Supportability adaptability, maintainability, internationalization,
configurability
The sub-factors include the following: -
Implementation resource limitations, language and tools, hardware
Interface constraints imposed by interfacing with external systems.
Operations system management in its operational setting.
Packaging for example, a physical box
Legal licensing and so forth
Use cases
Use cases are test stories, widely used to discover and record requirements. The
influence many aspects of a project including OOA/D and will be input to many
subsequent artifacts in the case studies.
Example:-
Process Sale
A customer arrives at a checkout with items to purchase. The cashier uses the POS
system to record each purchased item. The system presents a running total and line-item
details. The customer enters payment information, which the system validates and
records. The system updates inventory. The customer receives a receipt from the system
-
and then leaves with the items.
What are Actors, Scenarios and Use Cases?
An actor is something with behavior such as a person, computer system or organization.
A scenario is a specific sequence of actions and interactions between actors and the
system.
A use case is a collection of related success and failure scenarios that describe an actor
using a system to support a goal.
A use case model is the set of all written use cases; it is a model of the systems functionality and environment.
What are three kinds of Actors?
Primary actor Has user goals fulfilled through using services of the system under discussion. Eg:- the cashier.
Supporting actor Provides a service to the system under discussion. Eg:- automated payment authorization service.
Offstage actor Has interest in the behavior of the use case, but is not primary or supporting. Eg:- Government tax agency
What are three common use case formats?
brief One paragraph summary
casual Informal paragraph format
fully dressed All steps and variations are written in detail
Use Case Diagrams
Use case diagrams are used to illustrate the names of use cases and actors and the
relationship between them.
Other Requirements Artifacts
Supplementary Specification captures and identifies other kinds of requirements such as reports, documentation, packaging, supportability, licensing
and so forth.
-
Glossary captures terms and definitions
Vision summarizes the vision of the project
Business Rules capture long living and spanning tree rules or policies such as tax laws.
top related