1 / 61

Software Modeling and Design

Software Modeling and Design. Contents in Unit 1. Introduction to software design Design methods- procedural / structural and object oriented Requirement Vs Analysis Vs Architecture Vs Design Vs Development 4+1 Architecture UP COMET use case based software life cycle

rhempel
Download Presentation

Software Modeling and Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Modeling and Design

  2. Contents in Unit 1 • Introduction to software design • Design methods- procedural / structural and object oriented • Requirement Vs Analysis Vs Architecture Vs Design Vs Development • 4+1 Architecture • UP • COMET use case based software life cycle • Introduction to UML -Basic building blocks • Use case modeling, Use case template

  3. Model M:Abstractions from (really existing or only thought of ) things, people , processes and relationships between these abstractions. • To make predictions about the future • A model is always an approximation

  4. …. fM2 M2 M2 Analysis I2 fM1 M1 M1 Requirements Elicitation I1 R R fR Models of models of models... • Modeling is relative. We can think of a model as reality and can build another model from it (with additional abstractions). The development of Software-Systems is a Transformation of Models: Analysis, Design, Implementation,Testing

  5. Systems Development Life Cycle (SDLC) • Systems development project • Planned undertaking with fixed beginning and end • Produces desired result or product • Successful development project: • Provides a detailed plan to follow • Organized, methodical sequence of tasks and activities • Produces reliable, robust, and efficient system

  6. Phases of the Systems Development Lifecycle (SDLC)

  7. SDLC(cont..) • Project planning: Initiate, ensure feasibility, plan schedule, obtain approval for project • Analysis: Understand business needs and processing requirements • Design: Define solution system based on requirements and analysis decisions • Implementation: Construction, testing, user training, and installation of new system • Support: Keep system running and improve

  8. SDLC and problem-solving • Similar to problem-solving approach • Organization recognizes problem (Project Planning) • Project team investigates, understands problem and solution requirements (Analysis) • Solution is specified in detail (Design) • System that solves problem built and installed (Implementation) • System used, maintained, and enhanced to continue to provide intended benefits (Support)

  9. Analysis Phase of SDLC • Gather information to learn problem domain • Define system requirements • Build prototypes for discovery of requirements • Prioritize requirements • Generate and evaluate alternatives • Review recommendations with management

  10. Design Phase of SDLC • Design and integrate the network • Design the application architecture • Design the user interfaces • Design the system interfaces • Design and integrate the database • Prototype for design details

  11. Transition from Analysis to Design Analysis:A process of extracting and organizing user requirements and establishing an accurate model of the problem domain.(WHAT) Design:Process of mapping requirements to a system implementation that conforms to desired cost, performance, and quality parameters.(HOW)

  12. Transition from analysis to Design • Blurred line between analysis & design • Process of design leads to better understanding of requirements • Can be performed iteratively • No direct & obvious mapping exists between structured analysis and structured design. • OO, mapping from analysis to design does appear to be potentially more isomorphic.

  13. Two Approaches for Analysis & Design • Traditional Approach:SSAD(System Structured Analysis and Design) • Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams • Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts • OOAD • Designing systems using self-contained objects and object classes

  14. Structure Chart Created Using Structured Design Technique

  15. Structured Analysis • Define what system needs to do (processing requirements) • Define data system needs to store and use (data requirements) • Define inputs and outputs • Define how functions work together to accomplish tasks • Data flow diagrams and entity relationship diagrams show results of structured analysis

  16. Data Flow Diagram (DFD) created using Structured Analysis Technique

  17. Entity-Relationship Diagram (ERD) created using the Structured Analysis technique

  18. Structured Analysis Leads to Structured Design and Structured Programming

  19. OOAD methods Three major steps: 1. Identify the objects 2. Determine their attributes and services 3. Determine the relationships between objects

  20. Object-Oriented Approach • Views information system as collection of interacting objects that work together to accomplish tasks • OOA • OOD • OOP • Object-oriented analysis (OOA) • Defines types of objects that do work of system • Shows how objects interact with users to complete tasks

  21. Object-Oriented Approach (continued) • Object-oriented design (OOD) • Defines object types needed to communicate with people and devices in system • Shows how objects interact to complete tasks • Refines each type of object for implementation with specific language of environment • Object-oriented programming (OOP) • Writing statements in programming language

  22. General Advantages • Understandable • maps the “real-world” objects more directly • manages complexity via abstraction and encapsulation • Practical • successful in real applications • suitable to many, but not all, domains • Productive • experience shows increased productivity over life-cycle • encourages reuse of model, design, and code • Stable • changes minimally perturb objects

  23. Analysis class diagram

  24. The Unified Process (UP) • Object-oriented development approach • Offered by IBM / Rational • Booch, Rumbaugh, Jacobson • Unified Modeling Language (UML) used primarily for modeling • UML can be used with any OO methodology • UP defines 4 life cycle phases • Inception, elaboration, construction, transition

  25. The Unified Process (UP) (continued) • Reinforces six best practices • Develop iteratively • Define and manage system requirements • Use component architectures • Create visual models • Verify quality • Control changes

  26. Phases in UP UP is divided into four phases • Inception • Elaboration • Construction • Transition

  27. Iterations Iterations Iterations Iterations Inception Elaboration Construction Transition Iterations Each phase has iterations, each having the purpose of producing a demonstrable piece of software. The duration of iteration may vary from two weeks or less up to six months.

  28. The iterations and the phases

  29. Inception • The life-cycle objectives of the project are stated, so that the needs of every stakeholder are considered. • Scope and boundary conditions, acceptance criteria and some requirements are established.

  30. Elaboration • An analysis is done to determine the risks, stability of vision of what the product is to become, stability of architecture and expenditure of resources. • Define the architecture. • Validate the architecture. • Baseline the architecture

  31. Construction • The Construction phase is a manufacturing process. • It emphasizes managing resources and controlling operations to optimize costs, schedules and quality. • Develop and test components. • Manage resources and control process. • Assess the iteration

  32. Transition • The transition phase is the phase where the product is put in the hands of its end users. • It involves issues of marketing, packaging, installing, configuring, supporting the user-community, making corrections, etc.

  33. What is COMET? • Concurrent Object Modeling and architectural design mEThod • COMET is a design method for UML supporting OO systems • Concurrent • Distributed • Real-Time • Compatible with USDP (Unified Software Development Process)

  34. COMET Software Lifecycle • A highly iterative process • Focuses on the use case concept • Functional requirements are recorded in terms of actors and their use of the system, collected into use cases. • A use case is a series of interactions between one or more actors and the system

  35. COMET Software Lifecycle

  36. COMET Modeling • Requirements Modeling • Use cases are generated, and serve as the requirements for the system. • Throwaway prototypes can help to clarify the requirements. • Analysis Modeling • Static Models • Class Diagrams show the classes of the problem domain. • Dynamic Models • Show the problem domain objects participating in use cases.

  37. COMET Modeling (cont.) • Design Modeling • Software architecture is designed • Problem Domain (Analysis Mode) is mapped to Solution Domain (Design Model) • Subsystems are identified and structured • Emphasis is on designing distributed subsystems as configurable components that communicate with each other via messaging.

  38. What is UML? • Unified Modeling Language • OMG Standard, Object Management Group • Based on work from Booch, Rumbaugh, Jacobson • UML is a modeling language to express and design documents, software • Particularly useful for OO design • Not a process, but some have been proposed using UML • Independent of implementation language

  39. Why use UML • Open Standard, Graphical notation for • Specifying, visualizing, constructing, and documenting software systems • Language can be used from general initial design to very specific detailed design across the entire software development lifecycle • Increase understanding/communication of product to customers and developers • Support for diverse application areas • Support for UML in many software packages today (e.g. Rational, plugins for popular IDE’s like NetBeans, Eclipse) • Based upon experience and needs of the user community

  40. Brief History • Inundated with methodologies in early 90’s • Booch, Jacobson, Yourden, Rumbaugh • Booch, Jacobson merged methods 1994 • Rumbaugh joined 1995 • 1997 UML 1.1 from OMG includes input from others, e.g. Yourden • UML v2.0 current version

  41. History of UML

  42. Contributions to UML

  43. Systems, Models and Views • A model is an abstraction describing a subset of a system • A view depicts selected aspects of a model • A notation is a set of graphical or textual rules for depicting views • Views and models of a single system may overlap each other Examples: • System: Aircraft • Models: Flight simulator, scale model • Views: All blueprints, electrical wiring, fuel system

  44. UML Models, Views, Diagrams • UML is a multi-diagrammatic language • Each diagram is a view into a model • Diagram presented from the aspect of a particular stakeholder • Provides a partial representation of the system • Is semantically consistent with other views • Example views

  45. 4+1 View Model of Architecture End user Logical view Development view Programmers & software managers Scenarios Process View Physical View System Engineer Integrator

  46. Models, Views, Diagrams

  47. UML diagramming

  48. Basic Modeling Steps • Use Cases • Capture requirements • Analysis Model • Capture process, key classes • Design Model • Capture details and behaviors of use cases and domain objects • Add classes that do the work and define the architecture

  49. UML Baseline • Use Case Diagrams • Class Diagrams • Package Diagrams • Interaction Diagrams • Sequence • Collaboration • Activity Diagrams • State Transition Diagrams • Deployment Diagrams

More Related