Sei sulla pagina 1di 8

Entity Relationship Diagram: A Data Model: Will identify and structure all the items that the system

will need to hold data about, describing the data in a logical manner (independent of any particular technical means of storage) ER analysis: 1. Group similar objects into entity sets. Model all interactions between the objects in the entity sets by relationship and relationship sets. Identify relationship cardinality. Determine the attributes (or properties) of objects in the sets. One of the attributes of an entity set will be the identifier. 2. (Model relationship participation) *Rectangles: Entity sets ALWAYS NOUNS, *Diamonds: Relationships usually VERBS or prepositions(links different related entity sets) *Attributes: Describe the entities and relationships (unique = identifiers) OTHER FACTORS uni-directional naming (arbitrary which way you name it) N-ary (3 way) and derived relationship sets should be avoided CARDINALITY: 1:1, 1:N, N:1, N:M PARTICIPATION: Optional (O) or Mandatory Simple or multivalued (indicated with an asterisk*) identifiers of both entities should be included in relationship set Identifiers can be single valued or composite (eg: for vehicle: STATE,REG-NO.) An E-R Diagram describes the structure of data and relationships within it. It should not express the dynamics of how it is created, that is, it is not a flowchart.

Structured vs. Object Oriented Structured:  In the structured approach, things make up the data about which the system stores information => ERD.

 Takes a snapshot in time. Good for understanding how something works now.  Looks at processes and data flows.  Different tools used in analysis and design phases. Data flow diagram basic tool to show information flow, physical  Process something that transforms data.  Processes are described in Structured English  Looks at processes, the data used, inputs, and outputs. E-R - Diagram used to identify and structure all the items that the systems will need to hold data about.  Logical not physical description.  The data entities, the relationship between data entities, and the attributes of data entities are modelled using an ERD.  System is a collection of processes; processes interact with the data entity and accept inputs/ produce outputs. Overall: Relates easily to real life situation but can be difficult to convert into specifications to develop software, requires skills and judgement of the analyst to implement (design specification to programming). Object Oriented:  In the object-oriented approach, things are the objects that interact in the system.  Good for complicated systems and continuous maintenance.  System is a collection of interacting objects that interact with people and each other, objects send and respond to messages.  Shows the exact same capabilities but in a much more concise way, assuming that objects know how to perform basic services (add(), delete(), display() etc.)  Hard to understand what s happening but easy to turn into a program.  Models events into use cases/ use case diagrams and then develops them into object class diagrams. UML focused utilising; sequence, collaboration, state transition, event flow and object class diagrams.  UML focuses on objects (things) and relationships along with structure or behavioural diagrams. Structural things = classes, use cases, interfaces. Behavioural things = Interactions, state machines.

USE CASE: What a system does, not how it does the work. View of the system from the outside (external user), collection of scenarios about system use, early analysis Includes, communicates, includes, extends and generalises . Can be grouped into packages Use case diagram, individual use case.  Use Case Diagram a diagram to show the various user roles and how these roles use the system  Collaboration Diagram a diagram showing the objects that collaborate together to carry out a use case  Sequence Diagram a diagram showing the sequence of messages between objects during use case  State Transition diagram a diagram showing the life of an object in states and transition Describe what people do in achieving goals using business related tasks at a usage level. Generalise usage world scenarios and describe activities in the system. One use case model per system.

SEQUENCE DIAGRAM: A graphical representation of a use case scenario succession of interactions showing the processing A succession of interactions between classes or object instances over time, displaying the processing in a single scenario. Solid arrow = synchronous (wait for response), open = asynchronous  Collaboration diagram cannot easily describe information about concurrent messages or messages that are initiated simultaneously. It does not indicate information about the creation or deletion of objects within the scenario  Sequence diagram is developed to describe the detailed information about the interactions and messages within the scenario.  A sequence diagram gives an external view of object behaviour. It identifies the messages that the objects send and receive.

EVENT-FLOW DIAGRAM:

Individual use cases > individual sequence diagrams > all come together in event flow diagram (with properties and methods). OBJECT CLASS DIAGRAM: Attributes can be private (normal usually public. sign), public + sign, protected #, methods

Associative class (eg Student, Course, --- Section) used to break up many-tomany association between classes. 3 Types of whole/part relationships *Aggregation (whole is sum of its parts, whole removed parts remain eg. Student > Campus organisation ) *Collection (whole and its members eg library and voters, part is removed then whole retains its identity weak association. *Composition (stronger relationship = whole has responsibility for its parts, if whole is removed so are the parts. Eg insurance policy with riders) Gen/spec polymorphism method overriding (part has priority, more specific has priority) Finding classes (nouns) Finding methods/ properties (event flow properties from incoming and outgoing messages, methods from incoming messages)

STATE TRANSITION DIAGRAM:  The purpose of a state transition diagram is to describe the events that cause a change in state of the objects.  How an object performs its actions is called object behaviour. Each object is an instance of a class, and has a complete life cycle, from creation to destruction. It helps analysts, designers and developer understand the behaviour of the objects in the system. Reduces the guesswork from what an object is supposed to do.  State transition diagrams show class states and the events that cause them to transition between states.  An event happens at a specific time and place. They cause a change of state, or the transition fires  Each time an object changes state, some of its attributes must change.  There must be a method to change the attributes.

 Often there is a display screen or Web form to enter the attributes.  Single class per diagram, objects change their state in response to events and time.  The key concepts associated with both techniques are Events (external, temporal, state) and Things . This is associated with all modelling.

SYSTEM METHODOLOGIES: A collection of procedures, techniques, tools and documentation aids which will help the systems developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of subphases, which will guide the systems developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate information systems projects a methodology must have a philosophy : the nature of information systems the nature of the developers role(s) the nature of the development process

Advantages include: systematic approach to development, maintainable, welldocumented, improved quality, consistency across projects and information systems Each Project should be carefully analysed to understand its requirements technical, economic,social, risk

SDLC: Traditional older methodologies (involving flow charts, organisation charts grids etc), later comes data flow diagramming, ERD, normalisation etc. Base guidelines, emphasisesd project control, documentation, standards, quality control, rigid, highly structured. Is resource intensive, inflexible (top down, step by step approach), hard to visualise final system, management and strategic needs ignored, not well suited for small desktop systems and does not encourage user participation. User dissatisfaction, lack of creativity, piecemeal approach, emphasis on how (as apposed to why), management and strategic needs ignored Structured analysis

Functional decomposition, more iterative/ flexible, communication oriented, process-oriented (DFD s) Information engineering Data oriented (data first, process later), organisation wide perspective on planning of Information systems, focus on data and activities. Data analysis and management, alignment of business and IT, process modelling techniques, RAD, OO General trend towards aligning business and IT needs, expoiting IT for strategic advantage, decentrailisation, user participation, prototyping, incremental delivery. HARD system approaches precise situations SOFT system approaches fuzzy, ill defined, human factor in business, methodology to define changes, human and process over technique. Different viewpoints, different users. WORLD VIEW Overall goal is choosing most effective and efficient methodology it will effect hardware and software, recruitment and training. Analyse projects and characteristics. Options: SDLC classic model, once through, review at each phase, rigid V PROCESS necessity of validation, testing, allows reworking Spiral Model greater level of detail at each phase, confidence and probability of success, project evaluated regularly, considers risk Prototyping throw away investigation/ clarification, mock up of screens, partial working model, cosmetic local and global changes Incremental delivery breaks applications into small components, time boxing (but global picture neglected) JAD developers and users working together, speeds up communication/neg. RAD prototyping/ incremental development, quick delivery, small teams Agile Basically iterative methods with high user involvement that handle changes System Architecture ASK KEVIN WHETHER INCLUDED Every interesting software-intensive system has an architecture The most successful software architectures are intentional, manifest, and visible - and beautiful

- Architecture defines major components

- Architecture defines component relationships (structures) and interactions - Architecture omits content information about components that does not pertain to their interactions - Behavior of components is a part of architecture insofar as it can be discerned from the point of view of another component - Every system has an architecture (even a system composed of one component) - Architecture defines the rationale behind the components and the structure - Architecture definitions do not define what a component is - Architecture is not a single structure -- no single structure is the architecture

Performance = complexity x process x team x jobs  Inception Understand what to build  Elaboration Understand how to build it  Construction Build the product  Transition Deliver and adapt the solution

Misconceptions:  Architecture is just paper  Architecture and design are the same things  Architecture and infrastructure are the same things  <my favorite technology> is the architecture  A good architecture is the work of a single architect  Architecture is simply structure  Architecture can be represented in a single blueprint  System architecture precedes software architecture  Architecture cannot be measured or validated

 Architecture is a science  Architecture is an art

USE CASE VIEWS: *Logical (functionality, key abstractions, mechanisms). *Process (threads and processes that form the system s concurrency and synchronisation mechanisms). *Implementation (components to assemble and release the physical system) *Deployment nodes on hardware typology (configuration management)

Potrebbero piacerti anche