1 / 11

The JACOBSON ET AL. Methodology

The JACOBSON ET AL. Methodology. It covers the entire life cycle and stress traceability between the different phases, both forward & backward. Examples: OO Business Engg. (OOBE) & OO Software Engg. (OOSE) Use Cases: A use case is an interaction between users & a system.

aromer
Download Presentation

The JACOBSON ET AL. Methodology

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. The JACOBSON ET AL. Methodology • It covers the entire life cycle and stress traceability between the different phases, both forward & backward. Examples: OO Business Engg. (OOBE) & OO Software Engg. (OOSE) Use Cases: • A use case is an interaction between users & a system. • The use-case model captures the goal of the user & the responsibility of the system to its users.

  2. Use Cases In the requirement analysis, the user cases are described as one of the following: • Non formal text with no clear flow of events. • Text, easy to read but with a clear flow of events to follow (recommended style). • Formal style using pseudo code. The use case description must contain: • How and when the use case begins & ends. • The interaction between the use case & its actors, including when the interaction occurs and what is exchanged. • How & when the use case will need data stored in the system or will store data in the system. • Exceptions to the flow of events. • How & when concepts of the problem domain are handled.

  3. Use Cases The use-case model employs extends and uses relationships: • The extends relationship is used when we have one use case that is similar to another use case but does a bit more. • The uses relationship reuses common behavior in different use cases. Use cases can be viewed as concrete or abstract: An abstract use case is not complete and has no actors that initiate it but is used by another use case.

  4. Example: Use-case Model Supplier Library Checking out books Getting an interlibrary loan Doing research Member Reading books, newspapers Purchasing supplies

  5. Object-Oriented Software Engineering:Objectory Objectory is a method of OO development with the specific aim to fit the development of large, real-time systems. • This process, called use-case driven development, stresses that use cases are involved in several phases of the development, including analysis, design, validation & testing. • The use-case scenario begins with a user of the system initiating a sequence of interrelated events.

  6. Object-Oriented Software Engineering:Objectory Objectory is built around several different models: Use-case model: This model defines the outside(actors) & inside (use case) of the system’s behavior. • Domain object model: The objects of the real world are mapped into the domain objects. • Analysis object model: This model presents how the source code should be carried out & written. • Implementation model: This model represents the implementation of the system. • Test model: This model constitutes the test plans, specification, & reports.

  7. Use-Case Model Use-case model Express in Tested in Structured by Implemented by Realized by OK NOT OK Analysis model Design Model Testing Model Domain Object model Implementation Model

  8. Object Oriented Business Engineering (OOBE) OOBE is object modeling at the enterprise level. Analysis phase: • It defines the system to be built in terms of the problem-domain object model, the requirements model, & the analysis model. • The analysis process is iterative but the requirements & analysis model should be stable before moving onto subsequent models. Design & implementation phase: • This includes factors such as DBMS, distribution of process, constraints due to the programming language, available component libraries, & incorporation of graphical user interface tools. • The analysis objects are translated into design objects that fit the current implementation environment. Testing phase: • It includes unit testing, integration & system testing.

  9. Pattern “A pattern is an instructive information that captures the essential structure & insight of a successful family of proven solution to a recurring problem that arises within a certain context & system of forces”. • The main idea behind using patterns is to provide documentation to help categorize & communicate about solutions to recurring problems. • Pattern also explains why the solution is needed. • A pattern in waiting which is not yet known to recur is called a proto-pattern.

  10. Patterns continued Coplien[12] explains that a good pattern will do the following: • It solves a problem: Patterns capture solutions. • It is a proven concept: Patterns capture solutions with a track record, not theories or speculation. • The solution is not obvious: The best patterns generate a solution to a problem indirectly. • It describes a relationship: Patterns describe deeper system structure & mechanisms. • The pattern has a significant human component: The best patterns explicitly appeal to aesthetics & utility.

  11. Generative & Nongenerative Patterns “Generative patterns are patterns that not only describe a recurring problem, they can tell us how to generate something & can be observed in the resulting system architectures”. “Nongenerative patterns are static & passive, which describe recurring phenomena without necessarily saying how to produce them”.

More Related