1 / 189

Software Modeling and Design

Software Modeling and Design. UNIT 1. 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

jodiea
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 UNIT 1

  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. Introduction to software design, design methods- procedural / structural and object oriented, Requirement Vs Analysis Vs Architecture Vs Design Vs Development 4+1 Architecture, case study of transferring requirement to design, UP, COMET use case based software life cycle, Introduction to UML -Basic building blocks, Reusability, Use case modeling, Use case template • Case study – Transferring requirements into design using advanced tool

  4. 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

  5. …. 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

  6. 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

  7. Start of lecture. 15 Jan 2018

  8. Phases of the Systems Development Lifecycle (SDLC)

  9. 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

  10. 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)

  11. 1. Software Design • Software Design is the process by which an agent creates a specification of a software artifact, • intended to accomplish goals, • using a set of primitive components and • subject to constraints.

  12. e.g. of artifacts: • use cases, class diagrams, and • other Unified Modeling Language (UML) models, • requirements and design documents

  13. 2. Software Design Notation • A software design notation is a means of describing a software design either graphically or textually, or both. For example: class diagrams are a graphical design notation, and pseudocode is a textual design notation.

  14. A design notation suggests a particular approach for performing a design; however, it does not provide a systematic approach for producing a design.

  15. 3. Software Design Concept • A software design concept is a fundamental idea that can be applied to designing a system. • For example, • Information hiding is a software design concept.

  16. 4. Software Design Strategy • A software design strategy is an overall plan and direction for developing a design. • For example, • object-oriented decomposition is a software design strategy.

  17. 3. Software Design Method • A software design method is a systematic approach that describes the sequence of steps to follow in order to create a design, given the software requirements of the application. • It helps a designer or design team identify the design decisions to be made, the order in which to make them, and the structuring criteria to use in making them. • A design method is based on a set of design concepts, employs one or more design strategies, and documents the resulting design, using a design notation

  18. ANALYSIS VS DESIGN PHASE • Contd… from SDLC

  19. 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

  20. 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

  21. Transition from Analysis to Design

  22. 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 qualityparameters.(HOW)

  23. 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.

  24. 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

  25. Structured Analysis • Define what system needs to do (processing requirements) • Define data which the 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 Diagramsshow results of Structured Analysis

  26. DFD • Better understanding of the functions of the systems could be obtained by considering the flow of data through the system. • DFDs start at a high level of abstraction and proceed to more detailed levels

  27. There are essentially two different types of notations for data flow diagrams (Yourdon & Coad or Gane & Sarson) defining different visual representations for processes, data stores, data flow and external entities. • Yourdon and Coad type data flow diagrams are usually used for system analysis and design, while Gane and Sarson type DFDs are more common for visualizing information systems. • Visually, the biggest difference between the two ways of drawing data flow diagrams is how processes look. In the Yourdon and Coad way, processes are depicted as circles, while in the Gane and Sarson diagram the processes are squares with rounded corners.

  28. 1. Process Notations. • A process transforms incoming data flow into outgoing data flow.

  29. 2. Datastore Notations • Datastores are repositories of data in the system. They are sometimes also referred to as files.

  30. 3. Dataflow Notations • Dataflows are pipelines through which packets of information flow. • Label the arrows with the name of the data that moves through it.

  31. 4. External Entity Notations • External entities are objects outside the system, with which the system communicates. • External entities are sources and destinations of the system's inputs and outputs.

  32. Level 0 • Level 1 • Level 2

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

  34. ERD • There are three basic elements in ER-Diagrams:

  35. Entities are the "things" for which we want to store information. • An entity is a person, place, thing or event. • Attributes are the data we want to collect for an entity. • Relationships describe the relations between the entities.

  36. Name of the entity must be unique within this model. • In this case, the name of the entity is a name of type, rather than a specific instance of this type. • A concrete representative of the entity is called by the entity instance

  37. Entity-Relationship Diagram (ERD) created using the Structured Analysis techniqueCrows foot notation

  38. Crow's Foot notation was proposed by Gordon Everest, originally called Inverted Arrow. • According to this notation, the entity is represented by rectangle containing its name.

  39. Cardinality vs Modality • Cardinality refers to the maximum number of times an instance in one entity can be associated with instances in the related entity. • Modality refers to the minimum number of times an instance in one entity can be associated with an instance in the related entity.

  40. Cardinalitycan be 1 or Many and the symbol is placed on the outside ends of the relationship line, closest to the entity, • Modality can be 1 or 0 and the symbol is placed on the inside, next to the cardinality symbol. • For a cardinality of 1 a straight line is drawn. • For a cardinality of Many a foot with three toes is drawn. • For a modality of 1 a straight line is drawn. • For a modality of 0 a circle is drawn.

  41. Cardinality using Crows Foot Notation ONE Artist (can) perform "zero, one, or many" song(s).

  42. Structure Chart Created Using Structured Design Technique

  43. Structure Chart (SC) • A Structure Chart (SC) in software engineering and organizational theory is a chart which shows the breakdown of a system to its lowest manageable levels. • They are used in structured programming to arrange program modules into a tree. • Each module is represented by a box, which contains the module's name. • The tree structure visualizes the relationships between modules.[3]

  44. A structure chart is a top-down modular design tool, constructed of squares representing the different modules in the system, and lines that connect them. • The lines represent the connection and or ownership between activities and subactivities

  45. In structured analysis structure charts, according to Wolber (2009), "are used to specify the high-level design, or architecture, of a computer program. As a design tool, they aid the programmer in dividing and conquering a large software problem, that is, recursively breaking a problem down into parts that are small enough to be understood by a human brain. The process is called top-down design, or functional decomposition. Programmers use a structure chart to build a program in a manner similar to how an architect uses a blueprint to build a house. In the design stage, the chart is drawn and used as a way for the client and the various software designers to communicate. During the actual building of the program (implementation), the chart is continually referred to as "the master-plan

  46. Structure Charts - Invocation / Call • Call of subordinate module • Connector element • NOT a data flow • One specific form of control flow • Has a direction • No split or join • No label

More Related