1 / 132

Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html

Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html. Waterfall lifecycle with feedback. Waterfall with feedback, overlaps, and prototypes . Iterative lifecycle with increments .

wauna
Download Presentation

Course website: http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html

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. Course website: • http://www.cs.sjtu.edu.cn/~shengbin/course/SE/sesite/home.html

  2. Waterfall lifecycle with feedback

  3. Waterfall with feedback, overlaps, and prototypes

  4. Iterative lifecycle with increments • Iteration in software development is a repetition of some process with an objective to enrich the software product • Iterative lifecycle assumes increments – an improved or extended version of the product at the end of each iteration • Iterative lifecycle assumes builds – executable code that is a deliverable of an iteration. • Iterative lifecycle assumes short iterations between increments, in weeks or days, not months. • Models: • spiral • IBM Rational Unified Process (RUP) • Model Driven Architecture (MDA) • Agile lifecycle with short cycles

  5. Iterative lifecycle with increments

  6. Spiral model

  7. Rational Unified Process (RUP)

  8. Model Driven Architecture (MDA)

  9. Agile lifecycle with short cycles

  10. 13 XP practices • whole team (no barriers between all stakeholders) • metaphor (common language; “desktop metaphor”) • the planning game (user stories) • simple design • small releases (two-week iterations) • customer tests (acceptance tests) • pair programming • test-driven development (automated test first) • design improvement (refactoring) • collective code ownership • continuous integration (builds many times per day) • sustainable pace (no overtime) • coding standards

  11. Summary • Software engineering is concerned with development of large software systems. • The stages of software development process are referred to as software lifecycle phases. • Software process is part of a business process. • The immaterial and changeable nature of software are but two factors that make software engineering different from traditional engineering. • Software engineering is more than programming. • Software engineering is about modeling. • The lifecycle phases are requirements analysis, system design, implementation, integration and deployment, and operation and maintenance. • The lifecycle models are broadly divided into the waterfall models with feedback and the iterative models with increments. • Waterfall models are not suitable for modern software production. • There are four main representatives of iterative models: spiral, Rational Unified Process (RUP), Model Driven Architecture (MDA), and the agile model.

  12. 2. Software Modeling Language

  13. Topics • Structured modeling language • Data flow modeling • Entity-relationship modeling • Object-oriented modeling language • Class diagrams • Use case diagrams • Interaction diagrams • Statechart diagrams • Activity diagrams • Implementation diagrams

  14. The theme • Software engineering is about modeling • the outcome of software engineering – a program – is an executable model • Software modeling requires a language as a means of: • communicating between stakeholders • expressing development processes and artifacts at multiple levels of abstraction • The Unified Modeling Language (UML) • UML profiles to cater for specific domains and technologies • Model consists of one or more diagrams and any additional information stored in the project repository

  15. Structured modeling language • Structured programming • without goto statements, • loops and if statements as the main control constructs, • top-down approach to program design • Structured programming  structured modeling (structured analysis and design) • expresses the monolithic and procedural character of Cobol-style systems of the past • functional decomposition - top-down function-oriented approach to software development • visualization techniques • Data Flow Diagrams (DFDs) • Entity-Relationship Diagrams (ERDs) • structure charts

  16. Data Flow Diagrams (DFDs) • One of the most popular modeling technique in the history of SE • Mismatch with the object-oriented approach • The cornerstone of DFDs is functional decomposition

  17. Context diagram • Consists of: • one process only • a number of external entities • in- and out-flows between the process and external entities • Determines the place of the system with regard to its environment

  18. Level “0” diagram • Called also the overview diagram

  19. Level “1” diagram • Flow balancing • Data store

  20. Entity-Relationship (ER) modeling • A data modeling technique • Entity-Relationship Diagrams (ERDs) define just three modeling elements – entities, relationships, and attributes • An entity is a conceptual data structure, which represents a business fact or rule and which can be distinctly identified (usually) • A relationship represents an association between entity instances from different entity sets and, in some important cases, from a single entity set • An attribute is a data-value pair • single-valued • multi-valued attributes and composite attributes not normally supported

  21. ER crow’s foot notation • Attributes in entities • name, identifier indication, type, mandatory indication • Multiplicity of relationships • mandatory vs optional participation

  22. Object-oriented Methods • Object-oriented Analysis & Design (OOAD) – Grady Booch • The Object Modeling Technique (OMT) – Jim Rumbaugh • The Object-oriented Software Engineering method (OOSE) – Ivar Jacobson • Each one had its strengths and weaknesses.

  23. Object-oriented modeling language • The Unified Modeling Language (UML) “…is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.“ (UML, 2003b, p.1-1) • In the UML, visual modeling is an arrangement of so-called classifiers • A classifier is a model element that describes the system’s behavior or structure and that normally has a visual representation • Examples of classifiers include class, actor, use case, relationship • In a working system, classifiers manifest as objects • An object is a piece of software that has • state - defined by its attribute values • behavior - defined by services (operations) that an object can perform • identity – to differentiate between objects (even with the same state and behavior)

  24. UML • In 1996 the Unified Modeling Language was introduced as UML 0.9 and then 0.91 • Input was obtained from many, including TI, IBM, Microsoft, Oracle, and HP. • This led to UML 1.0 in 1997 • Eventually, the semantics and flexibility was improved resulting in UML 2.0 in 2003

  25. What is UML? • UML (Unified Modeling Language) • An emerging standard for modeling object-oriented software. • Resulted from the convergence of notations from three leading object-oriented methods: • OMT (James Rumbaugh) • OOSE (Ivar Jacobson) • Booch (Grady Booch) • Reference: “The Unified Modeling Language User Guide”, Addison Wesley, 1999. • Supported by several CASE tools • Rational ROSE • Together/J • ...

  26. Since its publication in 1991, the UML has been enhanced based on the work of many different authors.

  27. UML is for Visual Modeling A picture is worth a thousand words! Uses standard graphical notations Semi-formal Captures Business Process from enterprise information systems to distributed Web-based applications and even to hard real time embedded systems Sales Representative Places Order Customer Fulfill Order Item via Ships the Item Business Process

  28. UML is also for … Specifying • Building models that are: Precise, Unambiguous, Complete • UML symbols are based on well-defined syntax and semantics. • UML addresses the specification of all important analysis, design, and implementation decisions. Constructing • Models are related to OO programming languages. • Round-trip engineering requires tool and human intervention to avoid information loss • Forward engineering— direct mapping of a UML model into code. • Reverse engineering— reconstruction of a UML model from an implementation. Documenting • Architecture, Requirements, Tests, Activities (Project planning, Release management)

  29. Architecture & View UML is for visualizing, specifying, constructing, and documenting with emphasis on system architectures (things in the system and relationships among the things) from five different views Architecture -A set of significant decisions Design View Implementation View vocabulary functionality system assembly configuration mgmt. Use Case View behavior Process View Deployment View system topology distribution delivery installation performance scalability throughput

  30. Three basic building blocks of UML • Things • important modeling concepts (individual ones as the primitive kinds) • Relationships • tying individual things (i.e., their concepts) • Diagrams • grouping interrelated collections of things and relationships UML=Things+Relationships+Diagrams

  31. Things Structural — nouns of UML models. Behavioral — dynamic (verbal) parts of UML models. Grouping — organizational parts of UML models. Annotational — explanatory parts of UML models. Things=Structural+Behavioral+Grouping+Annotational

  32. (1) Structural Things in UML Nouns of UML models. Conceptual or physical elements. Active Class Class Collaboration Event Mgr thread time suspend( ) flush( ) stop( ) Window origin size open( ) close( ) move( ) Node Chain of Responsibility WebServer Place Order listbox IWindow Interface Component Use Case

  33. (2) Behavioral Things in UML Verbs of UML models. Dynamic parts of UML models: “behavior over time and space” Usually connected to structural things in UML. Two primary kinds of behavioral things: Interaction behavior of a set of objects comprising of a set of message exchanges within a particular context to accomplish a specific purpose. display State Machine behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. Idle Waiting

  34. (3) Grouping Things in UML Packages - one primary kind of grouping. - General purpose mechanism for organizing elements into groups. - Purely conceptual; only exists at development time. - Contains behavioral and structural things. - Can be nested. - Variations of packages are: Frameworks, models, & subsystems. Meeting Scheduler

  35. (4) AnnotationalThings in UML Explanatory parts of UML models Comments regarding other UML elements (usually called adornments in UML) Noteis one primary annotational thing in UML best expressed in informal or formal text. flexible drop-out dates

  36. Relationships Dependency Association Generalization Realization

  37. Dependency • A semantic relationship between two things in which a change to one thing (independent) may affect the semantics of the other thing (dependent). Directed is optional and label is optional.

  38. Associations A structural relationship that describes a set of links, a link being a connection between objects. Can bedirected labelsCan havemultiplicity & role names employee employer 0..1 * Aggregation a special kind of association. It represents a structural relationship between the whole and its parts. Represented by a black diamond.

  39. Realization • Asemantic relationship between two elements, wherein one element guarantees to carry out what is expected by the other element. Where? Between interfaces and classes that realize them… Between use cases and the collaborations that realize them...

  40. Six kinds of diagrams • state structure, • use case, • interaction, • statechart, • activity, and • implementation diagrams.

  41. Class diagrams • Class diagram: • expresses static structures of models, called also state models • visualizes classes (and interfaces), their internal structure, and their relationships to other classes • “a classis the descriptor for a set of objects with similar structure, behavior, and relationships.” (UML, 2003b, p.3-35) • Attribute is a structural (typed) feature of a class • attribute  data member, member variable, instance variable, field • Operation is a behavioral feature of a class • operation  member function, method

  42. Class Diagrams • Class diagrams represent the structure of the system. • Class diagrams are used • during requirements analysis to model problem domain concepts • during system design to model subsystems and interfaces • during object design to model classes. TariffSchedule Trip Enumeration getZones() Price getPrice(Zone) zone:Zone price:Price * *

  43. TariffSchedule Table zone2price Enumeration getZones() Price getPrice(Zone) TariffSchedule zone2price getZones() getPrice() TariffSchedule Classes Name Signature Attributes Operations • A class represent a concept. • A class encapsulates state (attributes) and behavior (operations). • Each attribute has a type. • Each operation has a signature. • The class name is the only mandatory information.

  44. Instances tariff_1974:TarifSchedule zone2price = { {‘1’, .20},{‘2’, .40}, {‘3’, .60}} • An instance represents a phenomenon. • The name of an instance is underlined and can contain the class of the instance. • The attributes are represented with their values.

  45. Actor vs. Instances • What is the difference between an actor and a class and an instance? • Actor: • An entity outside the system to be modeled, interacting with the system (“Pilot”) • Class: • An abstraction modeling an entity in the problem domain, inside the system to be modeled (“Cockpit”) • Object: • A specific instance of a class (“Joe, the inspector”).

  46. TripLeg pricezone Associations TarifSchedule Enumeration getZones() Price getPrice(Zone) * * • Associations denote relationships between classes. • The multiplicity of an association end denotes how many objects the source object can legitimately reference.

  47. The Direction of Association • Association can be directional or bidirectional • Given an order, we can find a specific customer while the order can not be indicated by a customer Order * 1 Customer

  48. Country City 1 1 Has-capital name:String name:String Point x:Integer y:Integer Polygon 1 * draw() 1-to-1 and 1-to-Many Associations 1-to-1 association 1-to-many association

  49. Many-to-Many Associations Company * * tickerSymbol StockExchange

  50. Association Classes • Example • Authorization services assign a merchant ID to each store for identification during communications • A payment authorization request from the store to an authorization service needs the merchant ID that identifies the store to the service • Furthermore, a store has a different merchant ID for each service Store AuthorizationService both placements of merchantID are incorrect address address because there may be more merchantID merchantID than one merchantID name name phoneNumber

More Related