OOSD_UNIT1 (1).pptx

OOSD !

1. Object Oriented System Design MODULE-1 Amity University, Noida

2. Course Objective The purpose of this module is to acquaint students with key aspects of object-oriented principles and systems modeling. It also aims to give students skills in the use of appropriate tools and familiarity with techniques applied at different stages of the software development lifecycle . Object oriented concepts have been the backbone of software solution design across platform such as embedded, internet and business solution. Over the years the market is growing stronger and bigger size. Meanwhile, the need for reliable and scalable software solution design is ever-increasing. Hence, the skilled professionals with good foundation of object oriented concepts are needed to fulfill the ever increasing requirements.

3. Module - 1 CLO1-Understanding the concept of  OOSA & OOSD with UML.   

4. Introduction to OOSD Technical approach Analyzing + Designing -> (Application, System, business) applying Object-oriented programming, using visual modeling for stake holderes and product quality

5. Designing software for large applications is a very complex task. It could arguably be said that there is no limit to how complex software design could get. The reason for this is that we generally design software to model some real-world phenomenon. 

6. This course forms a strong foundation in:- Understanding and design of modern computing systems. This course explores techniques that go into designing a modern microprocessor. Concepts of Object Oriented design

7. Stages of normal software development Analysis, Design, and Implementation

8. Phases in Object-Oriented Software Development object-oriented analysis.

9. object-oriented design Self contained Objects+ Classes

10. What is OOSD? The Object-Oriented Software Development Method (OOSD) includes object-oriented requirements analysis, as well as object-oriented design. OOSD is a practical method of developing a software system which focuses on the objects of a problem throughout development. OOSD's focus on objects early in the development, with attention to generating a useful model, creates a picture of the system that is modifiable, reusable, reliable, and understandable.

11. Object Oriented Design

12. What is UML UML, short for Unified Modeling Language, is a standardized modeling language consisting of an integrated set of diagrams. Developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

13. Origin UML is a notation that resulted from the unification of OMT from Object Modeling Technique OMT [James Rumbaugh  1991] - was best for analysis and data-intensive information systems. Booch [Grady Booch 1994] - was excellent for design and implementation. Grady Booch had worked extensively with the  Ada  language, and had been a major player in the development of Object Oriented techniques for the language. Although the Booch method was strong, the notation was less well received (lots of cloud shapes dominated his models - not very tidy) OOSE (Object-Oriented Software Engineering [ Ivar Jacobson 1992]) - featured a model known as Use Cases. Use Cases are a powerful technique for understanding the behavior of an entire system (an area where OO has traditionally been weak)

14. History

15. A software development will have many stakeholders playing a part. For Example: Analysts Designers Coders Testers QA The Customer Technical Authors

16. All of these people are interested in different aspects of the system, and each of them require a different level of detail. For example, a coder needs to understand the design of the system and be able to convert the design to a low level code. By contrast, a technical writer is interested in the behavior of the system as a whole, and needs to understand how the product functions. The UML attempts to provide a language so expressive that all stakeholders can benefit from at least one UML diagram.

17. UML 2 Diagram Structure below: Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts, there are seven types of structure diagram as follows:

18. UML Diagrams

19. Class Diagram Component Diagram Deployment Diagram Object Diagram Package Diagram Composite Structure Diagram Profile Diagram

20. Behavior diagrams show the  dynamic behavior  of the objects in a system, which can be described as a series of changes to the system over  time , there are seven types of behavior diagrams as follows: Use Case Diagram Activity Diagram State Machine Diagram Sequence Diagram Communication Diagram Interaction Overview Diagram Timing Diagram

21. Use case Modeling : Use case modeling is a useful tool for requirements elicitation. It provides a graphical representation of the software system's requirements. The key elements in a use case model are  actors  (external entities), and the  use cases  themselves. In outline, a use case is a unit of functionality (a requirement), or a service, in the system. A use case is not a process, or program, or function. Because use case models are simple both in concept and appearance, it is relatively easy to discuss the correctness of a use case model with a non-technical person (such as a customer). Use case modeling effectively became a practicable analysis technique with the publication of Ivar Jacobson's (1991) book “Object-oriented software engineering: a use case driven approach”. Jacobson has continued to promote this approach to system analysis to the present day, and it has now been formalized as part of the UML. However, use case modeling is not very different in its purpose and strategy from earlier techniques, such as structured viewpoint analysis

22. Unified Process

23. Components Relation in 3 components

24. Unified Process Unified Process is based on the enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation. The system is developed incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental software development. 

25. Unified Process: Phases and Major Milestones Inception The primary goal of the  Inception phase  is to establish the case for the viability of the proposed system. The tasks that a project team performs during Inception include the following: Defining the scope of the system (that is, what's in and what's out) Outlining a  candidate architecture , which is made up of initial versions of six different models Identifying critical risks and determining when and how the project will address them Starting to make the business case that the project is worth doing, based on initial estimates of cost, effort, schedule, and product quality

26. Elaboration The primary goal of the  Elaboration phase  is to establish the ability to build the new system given the financial constraints, schedule constraints, and other kinds of constraints that the development project faces. The tasks that a project team performs during Elaboration include the following: Capturing a healthy majority of the remaining functional requirements Expanding the candidate architecture into a full  architectural baseline , which is an internal release of the system focused on describing the architecture Addressing significant risks on an ongoing basis Finalizing the business case for the project and preparing a project plan that contains sufficient detail to guide the next phase of the project (Construction)

27. Construction The primary goal of the  Construction phase  is to build a system capable of operating successfully in beta customer environments. During Construction, the project team performs tasks that involve building the system iteratively and incrementally (see "Iterations and Increments" later in this chapter), making sure that the viability of the system is always evident in executable form. The major milestone associated with the Construction phase is called  Initial Operational Capability . The project has reached this milestone if a set of beta customers has a more or less fully operational system in their hands.

28. Transition The primary goal of the  Transition phase  is to roll out the fully functional system to customers. During Transition, the project team focuses on correcting defects and modifying the system to correct previously unidentified problems. The major milestone associated with the Transition phase is called  Product Release

29. Quiz 1

30. Case study – the NextGen POS system,

31. Open ended question Identify : Primary and secondary actors in NextGen POS Design Use Case for Process Sale

32. Symbols

33. There can be 5 relationship types in a use case diagram. Association between actor and use case Generalization of an actor Extend between two use cases Include between two use cases Generalization of a use case

34. Association Between Actor and Use Case This one is straightforward and present in every use case diagram. Few things to note. An actor must be associated with at least one use case. An actor can be associated with multiple use cases. Multiple actors can be associated with a single use case.

35. Association Between Actor and Use Case

36. Generalization of an Actor Generalization of an actor means that one actor can inherit the role of the other actor. The descendant inherits all the use cases of the ancestor. The descendant has one or more use cases that are specific to that role. Let’s expand the previous use case diagram to show the generalization of an 

37. Extending The extending use case is dependent on the extended (base) use case . In the below diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit Funds” use case. The extending use case is usually optional  and can be triggered conditionally. In the diagram, you can see that the extending use case is triggered only for deposits over 10,000 or when the age is over 55. The extended (base) use case must be meaningful on its own . This means it should be independent and must not rely on the behavior of the extending use case.

38. Include Relationship Between Two Use Cases Include relationship show that the behavior of the included use case is part of the including (base) use case. The main reason for this is to reuse common actions across multiple use cases. In some situations, this is done to simplify complex behaviors. Few things to consider when using the <<include>> relationship. The base use case is incomplete without the included use case. The included use case is mandatory and not optional.

39. Generalization of a Use Case This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant. This is used when there is common behavior between two use cases and also specialized behavior specific to each use case. For example, in the previous banking example, there might be a use case called “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

40. Quiz 2

41. References Barclay, K., & Savage, J. (2003).  Object-oriented Design with UML and Java . Elsevier. Booch, G. (1991).  object oriented design; with applications  (No. 04; QA76. 64, B6.).